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OBJECT-ORIENTED GLOBAL RESOURCE CONFLICT RESOLVER 

Copyright Notification 

Portions of this patent application contain material that is subject to 
5 copyright protection. The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document, or the patent disclosure, as it 
appears in the Patent and Trademark Office. All other rights are expressly 
resen/ed. 

10 Field of the Invention 

This invention relates to the configuration of computer systems and, 
more particularly, to an object-oriented apparatus and a method for assigning 
computer system resources to a plurality of I/O devices coupled to the 
computer system while avoiding conflicts among the devices for the 

15 resources. 

Background of the Invention 

A typical computer system is comprised of a variety of interconnected 
computer hardware components and devices. The terms "computer hardware 

20 components," "hardware components," 'peripheral devices" or simply 

"devices" ail refer to individual electronic devices which are coupled together 
to provide the computer system. For example, the computer keyboard, 
mouse, monitor, printer, hard disk drives, floppy disk drives, memory boards 
and the like constitute such devrces. Many of these components are mounted 

25 on a printed drcuit board generally referred to as a "planar^ or a 
"nrK)therboard." 

In many conventional architectures, the various components are 
connected together by means of a system bus which defines a medium over 
which information is transferred between the components. The system bus 
30 typically includes data, address and control lines which carry data, address 
and control infomnation between the various system components. For 



1 



wo 99/39268 



PCTAJS99/01740 



example, an intermpt signal may be sent from one or more of the peripheFai 
devices over the control lines of the system bus to the processor. 

The system bus and some basic hardware components connected to 
the system bus form an integrated system which is generally contained on the 
5 motherboard. In many personal computer systems, the system bus is 
connected to an extension called an "expansion" bus and the motherboard 
typically has one or more slots or connectors on the expansion bus, which 
connectors are referred to as "expansion slots" or "expansion connectors." 
To enhance the performance of the computer system, additional 

10 hardware components on printed circuit boards referred to as "device 
expansion boards", "device expansion cards", "expansion boards" or 
"expansion cards" can be plugged into the expansion slots. Depending upon 
the particular architecture of the computer system bus, an expansion card 
may constitute a bus adapter which has its own bus and slots. Other 

15 expansion cards can then be plugged into these latter slots. 

Expansion cards are generally coupled to a computer system to 
enhance the capabilities or perfonnance of the computer system. For 
example, one type of expansion card is a memory expansion card which may 
be used to Increase the anwunt of random access memory (RAM) available 

20 for use by the processor of the computer system. Other expansion cards 
include sound cards, SCSI bus adapters, graphics accelerator cards and 
others. 

Many expansion cards can be customized or configured by setting the 
values of one or more parameters. In some cards, the values are set 

25 manually by changing jumpers of switches located on the boards. In other 
cases, the parameters are set either manually or automatically by software. 
More particularly, the computer system is typically controlled and coordinated 
by a software program called a computer operating system (e.g. MS-DOS, 
OS/2, etc..) . Each device connected to the system bus interacts with the 

30 computer operating system through another software routine called a device 
driver. The device driver receives commands from the operating system and 
uses the commands to control the device. 
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In the case where device parameters are set by software, the device 
driver can often access the device parameters which parameters may be 
stored in the device itself, in the computer memory or In other portions of the 
computer system. The device parameters can then be set manually through 
5 the device driver software. In other cases, the device parameters are set 
automatically be means of configuration software which interacts with the 
driver software. 

Device drivers are provided as part of the computer operating system 
software for devices which are typically found in a conventional computer 

10 system. For example, operating system software typically includes device 
drivers for the computer keyboard, monitor, hard and floppy disk drives, and 
communication ports. Since there are so many different I/O expansion device 
configurations, these devices have device-specific device drivers which 
typically are not provided as part of the operating system software, but 

15 instead are stored as separate files. Such individual device drivers are 

generally referred to as installable devk:e drivers since they must be explicitly 
installed in the system memory before the associated device can be used. 

For example, in a computer which executes the MS-DOS operating 
system, an installation command for a particular installable device driver could 

20 be added to a boot file named "config.sys' which file is stored in a memory of 
the computer. When the computer processor initially begins executing the 
MS-DOS operating system, the processor executes the commands contained 
in the config.sys file. When device driver commands are included in this file, 
the processor executes the installation command for the installable device 

25 driver which loads the installable device driver into memory thereby providing 
access to the device. Alternatively, an application program which needs 
access to the device could load the driver during its initialization phase. 

In additbn to physically inserting an expansion card, installing the 
device driver and setting device parameters, in many cases it is also 

30 necessary to allocate computer resources to the expansion card. The term 
"computer resource" or more simply "resource" refers to anything within a 
computer system which either occupies memory of the computer system or 
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which is required to allow the computer system to perform a particular 
function. To print a page of a document, for example, certain resources such 
as character font sets, glyph sets, point tables, brush tables, user defined 
graphic Images and data that describes a page to be printed may be required 
5 to perform a print function. Thus, such resources may be referred to as 
printer resources. 

Expansion cards also provide I/O functions to the computer system. 
An I/O function is provided by a discrete device that is independently 
assigned I/O resources. Examples of I/O Functions are, Serial Port, SCSI 

10 port. Floppy, etc. I/O functions require I/O resources, which include, but are 
not limited to, computer memory space. I/O registers, interrupt signal lines, 
interrupt levels, intermpt sockets, direct memory access (DMA) channels, 
etc., which allow the I/O hardware components to operate with the computer 
system. Generally, the term I/O function is used in the discussion which 

15 follows rather than I/O device, since a single physical device or card may 
have several I/O functions implemented on it. Consequently, a function 
conresponds to a logical device rather than a physical device. 

The computer resources are often allocated to the I/O expansion 
boards in the same manner as hardware component parameters are set. For 

20 example, in some cases, resources can be allocated or selected manually, 
while in other cases, automatic configuration software allocates the 
resources. 

More specifically, many personal computers utilize a system bus 
architecture refenred to as the industry standard architecture (ISA) bus 

25 architecture. The ISA bus architecture has been implemented in a very large 
number of IBM and IBM-compatible personal computers. Computers 
employing the ISA bus architecture require the allocation of system resources 
such as menK)ry, I/O address spaces, direct memory access (DMA) channels, 
interrupt request lines and interrupt levels among multiple ISA expansion 

30 cards in the system. 

The types of expansion cards which may be used in computer systems 
having an ISA architecture may be divided into the following six categories: 
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(1) manually-configured ISA cards; (2) manually-configured motherboard 
devices: (3) manually-configured local bus cards; (4) auto-configuration ISA 
cards; (5) peripheral component interconnect (PCI) cards; and (6) PCMCIA 
cards. Auto-configuration ISA cards include mechanisms for card 
identification, resource usage determination, conflict detection and conflict 
resolution. This capability allows compatible operating system software to 
automatically identify and configure auto-configuration ISA cards without 
manual user intervention. 

The conventbnal ISA standard, however, does not define any 
hardware or software mechanism for allocating system resources. Thus, 
expansion cards and motherboard devices which confomi to the ISA standard 
may not include any on-board mechanisms for card identification, resource 
usage determination, conflict detection or conflict resolution. This can lead to 
problems in assignment of system resources. 

For example, depending upon the particular operating system (e.g. 
MS-DOS. WINDOWS, OS/2, WINDOWS 95 etc..) controlling the computer, it 
may be necessary to assign an interrupt line to a particular device: Often, 
each device requires a unique interrupt line. For example, a serial 
communication board installed on a computer operating with a WINDOWS 
graphical user interface must have a unique intenupt line coupled thereto. 
That is, no other device which is operating simultaneously can have the same 
interrupt line assigned to it 

In conventional systems, a user must examine the configuration of 
each installed device to determine which. If any, intenrupt line each device is 
using aruJ which interrupt lines are unused. The user then selects an unused 
interrupt line to couple to the serial communication board. The selection of 
the interrupt line may be Implemented on the ISA card manually by 
connecting so-called jumper wires (or more simply jumpers), opening or 
closing particular tenminals of dual in-line pin (DIP) switches which are located 
on the expansion cards, or via the device driver. Thus, a user must devote a 
relatively large amount of time to configuring a conventional ISA card. 
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In addition to the above, the configuration files of the computer system 
may also need to be updated to allow the computer system to recognize that 
an additional device has been added to the computer system. When a 
problem does arise, users typically must manually resolve resource 
5 allocations by refening to documentation provided by the manufacturer of the 
expansion card involved In the resource allocation. 

A problem, refenBd to as a resource conflict, can arise however, if two 
or more devices simultaneously attempt to use the same computer system 
resource, such as the same, or overiapping, memory regions of the same 

10 memory device. When such a resource conflict occurs, one or more of the 
devices involved in the conflict may not operate conrectly or the computer 
system may not operate correctly or may even stop operating altogether (i.e., 
the computer system becomes "hung-up"). This problem is particulariy acute 
when resources must be manually allocated. In this latter case, the user may 

15 be unsophisticated and not able to property allocate resources. Many 
computer systems come preconfigured with I/O devices such as a mouse, 
communication ports, etc. and resources are already allocated when the user 
receives the system. In these cases, it may be difficult for the user to 
ascertain which resources are already allocated even if the user is 

20 sophisticated enough to allocate resources. 

In order to assist the user in manually selecting free resources, some 
expansion cards come with resource checking programs that attempt to 
determine which resources are already in use. These programs are run 
t}efore a user physically inserts an expansion card and generally identify 

25 resources which are not in use and which would satisfy the requliBments of 
the card. One problem which arises with such programs is that, often, the 
resources are not in use when the checking program is run because the card 
which uses the resources is not active. Therefore, a resource shows up as 
free, when it is not. Later, when all cards are active, a resource conflict 

30 occurs. 

In conventional computer systems, when a resource conflict arises, a 
user must ascertain the cause of the resource conflict by detennining which 
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computer system resource is being accessed by each device and which 
devices are attempting to access the same resource. Once the user has 
ascertained the cause of the resource conflict, the user must then devise a 
plan to resolve the resource conflict. This Is often a time consuming effort, 
since the user must detennine which computer resources each device In the 
computer system uses, often by trial and error, and then reassign available 
computer resources to devices involved In the resource conflict. 

In addition to ISA cards, some computer systems employing an ISA 
architecture are provided having expansion slots which handle additional bus 
architectures. For example, some expansion slots are refen^ed to as local bus 
slots and accommodate a "local bus" card. Local bus slots typically accept 
expansion cards such as video adapter cards or mass storage cards. Cards 
conforming to this architecture have an intemai bus structure that allows 
information to be transfenred between components on the card without 
involving the system bus. Use of the intemai local bus improves the 
perfomnance of the computer system. Generally, computer systems 
employing the ISA architecture can operate with a variety of local bus 
architectures including but not limited to the video electronics standards 
association (VESA) bus architecture. However, many of the local bus 
architectures do not include any mechanism for identification and automatic 
configuration of the cards plugged into their slots. That is, many expansion 
cards employing local bus architecture cards are not auto-configuratlon 
expansion cards. 

Rather, such local bus cards are typically configured manually by 
connecting jumper wires and setting DIP switches, as is done with expansion 
cards which confonm to the conventional ISA standard. Since conventional 
ISA cards and manually-configured local bus cards are configured in the 
same manner, these types of cards will collectively be refenred to herein as 
"manual I/O expansion cards" or "manually-configured I/O expansion cards." 

One local bus architecture refenred to as a Peripheral Component 
Interconnect (PCI) architecture accepts expansion cards which conform to a 
PCI standard. Expansion cards which conform to the PCI standard are auto- 
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configurable in that they include mechanisms for card identification and 
resource usage determination. 

In addition in some computers, a motherboard may be provided having 
a socket which accepts an expansion card that conforms to a PCMCIA 
standard. Expansion cards confbnning to the PCMCIA standard can be 
inserted into a system still having power applied thereto (i.e. the computer 
system need not be turned off while the PCMCIA expansion card is coupled 
to the computer). Furthennore. expansion cards confonrning to a PCMCIA 
standard can be configured with software rather than via jumper wires and 
DIP switches. Thus, computer systems which only include expansion cards 
which conform to either the auto-configurable ISA, PCI or PCMCIA standards 
are fully auto-configurable. 

Some computer systems, however, include expansion cards which 
conform to the manually-configured ISA and local bus standards as well as 
expansion cards which conform to the auto-configurable ISA, PCI or PCMCIA 
stiandards. Thus, such computer systems require some user intervention in 
configuring the manually-configured I/O expansion cards. 

Computer systems which accept manually-configured I/O expansion 
cards require some mechanism to specify to the operating system software 
the configuration information for such expansion cards. Certain manually- 
configured expanston cards may be identified by device-specific probing 
techniques. That is, configuration infonmation of the expansion card may be 
detemnined by reading and writing to device specific hardware ports of the 
expansion card. However, such probing techniques are not always reliable. 
Furthermore, some expansion cards are not compatible with probing 
techniques. Thus, conventional techniques for configuring devices in 
computer systems having an ISA bus architecture either use a configuration 
file in memory to specify the resource assignment infonnation or hard code 
the resource assignment information into the conresponding device drivers. 

In the case of expansion boards which incorporate an additional bus 
architecture, a program called a resource manager is used to store and 
manage the configuration and resource allocation information for the devices 
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plugged into the additional bus. A problem arises, however, In that, in 
conventional systems, a separate resource manager is used for each different 
type of expansion bus. For example, in a computer system having both a 
Peripheral Component Interconnect (PCI) bus and a Personal Computer 
Memory Card Interface Association (PCMCIA) bus, the resources used by the 
PCI expansion card and the resources used by PCMCIA expansion card 
would be managed by separate resource managers located on each 
expansion card. These separate resource managers typically do not share 
information and thus neither resource manager contains any information as to 
which resources the other resource manager is using, leading to possible 
resource conflicts. 

It would, therefore, be desirable to provide a system which 
automatically detects and resolves resource conflicts between two or more 
devices in the computer system. Such resource conflicts may occur, for 
example, between two devices coupled to the mothertward via an expansion 
card or t>etween a device on the mothert>oard and a device on an expansion 
card. 

Summary of the Invention 

In accordance with the present invention, a single resource manager 
assigns system resources to all hardware devices in the computer system, 
including hardware devices that are both "plug and pla/ software 
programmable, hardware devices that are manually-configurable and the 
system mothertx>ard. The resource manager includes a conflict resolver 
module which resolves conflicts which arise in the computer system over the 
allocation of system resources. Such system resources include, but are not 
limited to, memory ranges, input-output (I/O) register ranges, intenrupt request 
lines and direct memory access (DMA) channels. 

Resource requirements for each device are obtained by recognizer 
objects which are customized versions of standardized objects ttiat are part of 
the resource resolver flramework. Resource requirements are automatically 
obtained from cards which contain on-board memories. Requirements for 
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manual cards are obtained from a pre-programmed database which may 
contain information generated by board manufacturers. All resource 
requirements are encapsulated in resource usage objects which have a 
standard Interface that works with the global resource resolver. The resource 
5 usage objects also encapsulate resource assignments generated by the 
global conflict resolver and thus contain complete information regarding 
resources for each device. The resource usage objects are stored in a 
hardware configuration database by recorder objects which are specialized 
for each device. The stored resource usage objects can be used both during 

10 system booting and during manual system reconfiguration. 

In accordance with a further aspect of the present invention, a method 
for identifying system resources and devices involved in a resource conflict 
includes the steps of identifying each expansion bus coupled to the computer 
system; identifying, for each of the expansion buses, each expansion card 

15 coupled thereto; identifying each of the I/O functions on each of the 

expansion cards; identifying each of the resource requirements on each of the 
expansion cards; registering each of the resource requirements for each of 
the I/O functions on each expansion card with a resource conflict resolver 
module and computing conflict-free resource assignments from the resource 

20 requirements registered with the resource conflict resolver module. 

In a preferred embodiment, the resource conflict resolver module uses 
object oriented programming (OOP) techniques, in such an embodiment, a 
single I/O resource conflict resolver object is created for all devices in the 
computer system by instantiating the conflict resolver object from a conflict 

25 resdver dass. 

Brief Description of the Drawings 

Figure 1 is a block diagram of a computer system having a resource 
manager with a resource conflict resolver which operates in accordance with 
30 the present invention; 

Figure 2 Is a schematic block diagram illustrating the components of a 
resource manager and their relationship to other system components. 
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Figure 3 is a schematic block diagram of the interaction between 
resource manager objects which are Involved in the assignment of resources 
and resolution of conflicts which occur during the initial installation of a 
manually-configured card; 
5 Figure 4 is a schematic block diagram of the interaction between 

resource manager objects which are involved in the assignment of resources 
and resolution of conflicts which occur during the initial installation of a "plug 
and play" card; 

Figure 5 is a schematic block diagram of the interaction between 
10 resource conflict resolver objects which are involved in the assignment of 
resources and resolution of conflicts which occur during system boot up; 

Figure 6 is a schematic block diagram of the interaction between 
resource conflict resolver objects which are involved in the assignment of 
resources and resolution of conflicts which occur during system boot up; 
15 Figures 7*1 1 are a series of Booch diagrams illustrating the 

relationships between classes in an expansion bus framework which can be 
used to model expansion buses in a computer system; 

Figure 12 is an illustrative flowchart showing an overview of the 
resource conflict resolutton process; 
20 Figure 1 3 is an Illustrative flowchart showing the method by which a 

collectton of possible resource assignments are built from the card objects; 

Figures 14A and 14B, when placed together fonm an illustrative 
flowchart showing the method by which conflicts are resoh^ed; 

Figure 15 is a Booch diagram illustrating class relationships concerning 
25 the functbn resource assignment classes; 

Figure 16 is a Booch diagram illustrating class relationships 
concerning the possible I/O resource assignment classes; 

Figure 17 is a Booch diagram illustrating class relationships concerning 
the configuration recorder classes; 
30 Figures 18A and 18B are Booch diagrams illustrating class 

relationships concerning the configuration option retriever classes; 

11 
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Figure 19 is a Booch diagram illustrating class relationships concerning 
manual I/O card classes; 

Figure 20 is a Booch diagram illustrating class relationships conceming 
card recognizer classes; 
5 Figures 21 A and 21 B are Booch diagrams illustrating class 

relationships conceming configuration recorder classes; 

Figure 22 are Booch diagrams illustrating dass relationships 
conceming manual, plug-and-play and PCI card classes; 

Figure 23 is a Booch diagram illustrating class relationships conceming 
10 function resource classes; and 

Figure 24 are Booch diagrams illustrating class relationships 
concerning various miscellaneous classes. 



Detailed Description of the Preferred Embodiment 

15 Refem'ng now to Figure 1, a computer 100 includes a central 

processing unit 102 which may be one or more conventional microprocessors 
interconnected via a system bus 122. The computer 1 00 may be, for 
example, an IBM® or IBM® compatible computer or aitemativeiy computer 
100 may be an Apple® Macintosh® computer or an Apple® compatible 

20 computer. Thus, the computer 100 typically has stored in memory 1 12 
thereof a computer operating system such as the IBM OS/2® operating 
system, the Apple System/7® operating system a DOS operating system or a 
WINDOWS® operating system. 

Also coupled to system bus 122 are a plurality of devices including a 

25 random access memory (RAM) 1 12, a read only memory (ROM) 1 14, a hard 
disk drive 1 16, a keyboard 126, a mouse 128 and monitor 146. Each 
hardware device in computer 100 has a controller which is coupled between 
ttie hardware device and the system bus 122. A controller is attached to the 
actual peripheral device and operates the device on behalf of the processor. 

30 Thus, a keyboard/mouse controller 124 is coupled between system bus 122 
and the keyboard 126 and mouse 128. Similarly, a hard disk controller 120 is 
coupled between the system bus 122 and the hard disk drive 1 16 and video 
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controller 144 is coupled between system bus 122 and monitor 146. Also, 
coupled to system bus 122 is a memory controller 104, a bus controller 106. 
and an intenupt controller 108. A DMA controller 130 can be used to control 
direct data transfers into memory 112. 
5 Processor 1 02 operates devices by programming the respective 

controllers. For example, the hard disk drive 1 16 is connected to the hard 
disk controller 120 which is programmed by processor 102. Each controller 
120, 124 and 144 includes internal registers used to program the respective 
device. Command operations, status operations, and data transfers with the 

10 device, are initiated by programming of the controller through its registers. 

Controllers also contain device buffers for data transfer. For example, 
the hard disk controller 120 contains registers for programming hard disk 
operations and a disk buffer. When a read operation occurs, the processor 
102 programs the controller 120 to perfomi a read from the hard disk drive 

15 116. The controller 120 initiates the operation and reads the data to the disk 
buffer within the controller 120. The data in the disk buffer are later 
transferred across the bus 122 to a memory location specified in the read 
request to the device driver. 

Each of the controllers 120, 124 and 130 and system bus 122 are 

20 physically tocated on a motherboard 111. Also coupled to bus 122 and 
located on the motherboard are a plurality of expansion stots 150A-150N. 
Various expansion cards 140A -140N may be inserted into the expansbn 
slots 150A. For example, the video controller 144 may be coupled to system 
bus 122 via an expanston slot 150B. Likewise a plurality of bus adaptors 

25 142A - 142N, may also be coupled to system bus 122 by inserting the 

appropriate cards into slots 150C - 150N. An expansbn bus 138A-138N may 
be inserted into each of the bus adapters 142A and 142N. Coupled to each 
expansion bus may be a plurality of devices such as an I/O device 132 and 
CD ROM 134 and additional memory 136. 

30 In accordance with the present invention, computer 100 also includes a 

resource manager 110 which identifies and resolves system resource 
conflicts that arise within the computer 100. It should be noted that computer 

13 
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100 includes the single resource manager 1 10 which manages each 
expansion card 140A - 140N, each expansion bus 138A - 138N and 
expansion cards, such as cards 132, 134 and 136 on the exapnsion busses 
coupled to the computer system 100. Thus, if expansion bus 138A 
5 corresponds to an ISA expansion bus and expansion bus 138N corresponds 
to a PCMCIA expansion bus, resource manager 110 still managers the 
system resources used by each of the expansion buses 138A, 138N. Since 
computer 100 includes only the single resource manager 110, resource 
manager 1 10 tracks both the system resources and the devices attempting to 

10 access the system resources on all of the expansion cards and buses 
coupled to the computer 100. 

In a prefenred embodiment, the present invention may be implemented 
with "object-oriented'* computer programming techniques. Object-oriented 
computer programming techniques involve the definition, creation, use and 

15 destruction of software entities referred to as "objects." Each object is an 
independent software entity comprised of data called "attributes'* and software 
routines called "member functions" or "methods" which manipulate the data. 

One characteristic of an object is that only methods of that object can 
change the data contained in the object The term "encapsulation" describes 

20 the concept of packaging the data and methods together in an object. 

Objects are thus said to encapsulate or hkJe the data and methods included 
as part of the object. Encapsulation protects an object's data from aribitrary 
and unintended use by other objects and therefore prevents an object's data 
from corruptton. 

25 To write an object-oriented computer program, a computer 

programmer conceives and writes computer code which defines a set of 
"object classes" or more simply "classes." Each of these classes serves as a 
template whk:h defines a data structure for holding the attributes and program 
instructions which perfonm the method of an object. Each class also includes 

30 a means for creating an object firom the class template. The means for 
creating is a method refen^d to as a "constructor. " 



14 



wo 99/39268 



PCTAJS99/01740 



When a processor of a computer executes an object oriented computer 
program, the processor generates objects from the dass infonmation using 
the constructor methods. During program execution, one object is 
constructed, which object then constructs other objects which may, in turn, 
5 construct other objects. Thus, a collection of objects which are constructed 
from one or more classes form the executing computer program. 

Inheritance refers to a characteristic of object oriented programming 
techniques which allows software developers to re-use pre-«xisting computer 
code for classes. The inheritance characteristic allows software developers 

10 to avoid writing computer code from scratch. Rather, through inheritance, 
software developers can derive so-called subclasses that inherit behaviors 
from base classes. The software developer can then customize the data 
attributes and methods of the subclasses to meet particular needs. 

With a base-class/sut>-class relationship, a first method having a 

15 panicular name may be implemented In the base-class and a second different 
method with the same nanrte may be implemented differently In the sub-dass. 
When the program Is executing, the first or second method may be called by 
means of a statement having a parameter which represents an object. The 
particular method which Is called depends upon whether the object was 

20 created from the dass or the sub-class. This concept is referred to as 
polynrK}rphism. 

For example, assume a computer program indudes a dass called 
Employee. Further assume that dass Employee indudes a memt)er function 
which defines a series of method steps to be carried out when a woricer 

25 retires from the company. In an object-oriented implementation, the retire 
method is automatically inherited by sub-dasses of dass Employee. Thus if 
a dass called Executive Is a sub-dass of the class called Employee, then 
dass Executive automatically inherits the retire method which is a member 
function of the class Employee. 

30 A company or organization, however, may have different methods for 

retiring an employee who is an executive an employee who is not an 
executive. In this case, the sub-dass Executive could Indude its own retire 

15 
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method which is performed when retiring an employee who is an executive. 
In this situation, the method for retiring executive employees contained in the 
Executive class overrides the method for retiring employees in general 
contained in the Employee class. With this base class/subclass arrangement 
5 another object may include a method which invokes a retirement method. 
The actual retirement method which is invoked depends upon the object type 
used In the latter call. If an Executive object type is used in the call the 
overriding retirement method is used. Othenvise the retirement method in 
the base-class is used. The example is polymorphic because the retire 

10 operation has a different method of implementation depending upon whether 
the object used in tiie call is created from the Employee class or the 
Executive dass and this is not determined until the program runs. 

Since the implementation and manner in which data attributes and 
member functions within an object are hidden, a method call can be made 

15 wittiout knowing which particular method should be invoked. Polymorphism 
thus extends the concept of encapsulation. 

Object-oriented computer programming techniques allow computer 
programs to be constructed of objects that have a specified behavior. 
Several different objects can be combined in a particular manner to construct 

20 a computer program which performs a particular function or provides a 

particular result Each of the objects can be built out of other objects tiiat in 
turn can be built out of other objects. This resembles complex machinery 
being built out of assemblies, subassemblies and so on. 

For example, a circuit designer would not design and fabricate a video 

25 cassette recorder (VCR) transistor by transistor. Rather, the circuit designer 
would use circuit components such as amplifiers, active filters and the like 
each of which may contain hundreds or thousands of transistors. Each circuit 
component can be analogized to an object which perfomis a specific 
operation. Each circuit component has specific structural and functional 

30 characteristics and communicates with other circuit components in a 
particular manner. The circuit designer uses a bill of materials which lists 
each of the different types of circuit components which must be assembled to 
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provide the VCR. Similarly, computer programs can be assembled from 
different types of objects each having specific structural and functional 
characteristics. 

The term "dient object," or more simply "client," is any object that uses 
5 the resources of another object which is typically referred to as the "server 
object" or "server." The temri "framewori^" can refer to a collection of inter- 
related classes that can provide a set of services (e.g. services for securities 
and bond trading) for a particular type of application program. Altematively, a 
framework can refer to a set of inter-related classes that provide a set of 

10 services for a wide variety of application programs (e.g. foundation class 
libraries for providing a graphical user interface for a Windows system). A 
framework thus provides a plurality of individual classes and mechanisms 
which clients can use or adapt. 

An application framework refers to a set of classes which are typically 

15 compiled, linked and loaded with one particular application program and 
which are used by the particular application program to implement certain 
functions in the particular application program. A system framework, on the 
other hand, is provided as part of a computer operating system program. 
Thus, a system framework is not compiled, linked and loaded with one 

20 particular application program. Rather, a system framework provides a set of 
classes which are available to every application program k>eing executed by 
the computer system which interacts with the computer operating system. 

Resource manager 110, and its components, will be described in 
detailed below in conjunction with Figures 2-17. In summary, resource 

25 manager 110 detects and resolves resource usage between I/O functions oh 
different buses in computer system 100. After detecting the existence of a 
resource conflict, the resource manager 1 10 computes a conflict-free set of 
system resource allocations between all I/O functions in the computer system 
regardless of the type of expansion bus or the type of cards plugged into the 

30 busses^ Resource manager 110 assists in booting the computer's I/O system 
by dynamically instantiating configuration recorders for the expansbn cards 
and motherboard in an ISA system. Bus systems with only plug & play cards 
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are fully auto-cx)nfigurable. However, it is recognized that manually-configured 
cards such as manual I/O cards and system board devices may coexist with 
auto-configurable cards in the same system. Such systems require some user 
intervention in configuring the manually-configured cards. 

Figure 2 is a schematic block diagram illustrating the components of 
computer 200 including the components of resource manager 110 and their 
relationship to other system components. In figure 2, elements which 
con-espond to ttiose in Figure 1 are given corresponding numbers. For 
example, system bus 122 illustrated in Figure 1 corresponds to system bus 
222 in Figure 2. 

In order to compute and manage conflict-free resource assignments, 
the resource manager 110 includes a resource conflict resolver module 220. 
A bus/card recognizer system 270 coupled to the resource conflict resolver 
module 220 recognizes the expansion cards 140A - 140N and busses 138A - 
138N connected to the system, and, retrieves information firom those busses 
and cards which store, on-board, resource requirements, such as plug and 
play cards. Some cards do not contain on-board storage for resource 
requirements and a configuration option database 206 is used to store the 
resource requirements for ttie I/O functions on these expansion cards. 
Illustinatively. ttie configuration option database 206 is a persistent database in 
which entries nnay be created during the installation of a manually-configured 
I/O expansbn card by the user, or by a setup program run by the user during 
installation of the card. The setup program installs configuration infonnation 
provided by the card manufacturer in the database 206. The bus/card 
recognizer system 216 retrieves infonnation from the configuration option 
database 206 for those busses and cards which do not store resource 
requirements. 

The configuration of the mottierboard 111 is detemiined by a 
motiierboard configuration recognizer 210 which includes a slot identifier 
mechanism (not shown) for creating a hardware interface identifier for each of 
the expansion slots 150A - 150N on the system bus 122. The bus/card 
recognizer system uses ttie slot identifiers as keys to register the resource 
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requirements for the I/O functions on the expansion cards 140A - 140N with 
the resource conflict resolver module 274. 

As described in detail below, the resource conflict resolver nKxJule 220 
uses the bus/card Information from the recognizer system 216 to generate a 
set of conflict-free resource assignments. If the resource conflict resolver 
module 220 encounters conflicts while producing such an assignment, it 
generates information, such as an identity of the conflicting resources, a 
conflicting period, an identity of conflicting I/O functions, etc.. which 
information is encapsulated in a resource conflict object 221 provided by the 
I/O resource conflict module 220 to the user. 

Once the resources have been assigned by means of the inventive 
system, the various assignments are stored by the card configuration 
recorder system 214 in a hardware configuration database 204. The 
configuration of the motherboard is recorded in database 204 by the 
motherboard configuration recorder 208. As will be described below in detail 
the hardware configuration database 204 is used by the computer boot 
system 202 during subsequent boots to determine which recognizers to 
construct and to retrieve previously-stored resource assignments. 

If the resource manager 170 is implemented via the aforementioned 
object oriented programming techniques, then tiie bus recognizer system 216 
and recorder system 208 and 214 can be implemented as parts of 
frameworics which generally describe the behaviors of the various busses and 
cards. For example, an expansion bus frameworic can include a set of 
classes that represent the general behavior of various expansion buses. For 
a specific type of expansion bus. a specific set of subclasses are derived from 
the classes provided by the expansion bus framework. The expansion bus 
framework provkJes a common nruxJel for recognizing expansion cards, 
registering the resource requirements of I/O functions on the expansion cards 
and instantiating configuration recorder objects for each of the expansion 
cards on various expansion buses. Similar frameworks are provided for the 
auto-configurable expansbn cards, the manually configurable cards and the 
mothertx>ard. 
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If the resource conflict resolver module 220 Is implemented as an 
object-oriented computer program, the conflict resolver 220 may be an object 
which is created from classes that are part of a conflict resolver framework 
which includes a plurality of classes which encapsulate various 
5 representations (e.g. adapter descriptor files of micro-channel architecture 
cards and configuration files of EISA cards) of resource requirements and 
constraints by the expansion cards 140A - 140N. These classes provide a 
bus independent model for detecting and resolving conflicts in resource 
usage which arise between multiple I/O functions on the expansion cards and 

10 motherboard of the computer. The important abstractions of the I/O conflict 
resolver flramework are briefly discussed below and are discussed in detail in 
conjunction with Figures 7-9. 

The description which follows is divided into two distinct phases for two 
types of expansion boards. The first phase concems the operation of the 

15 conflict resolver system when a new expansion board is installed into the 
computer system 200. Board installation is discussed for both plug and play 
and manually-configured boards. 

Manually-configured I/O expansion cards are not configurable, via 
software, as are auto-configurable expansion cards. Rather, manually- 

20 configured I/O expansion cards are configured by manually connecting 

jumper wires or setting DIP switches on the card. Thus, in computer systems 
which include manually-configured I/O expansion cards, the resource 
requirements of each of the manually-configured I/O expansion cards must be 
satisfied first so that the auto-configurable cards can be configured with the 

25 remaining resources. 

When a manually-configured I/O expansion card is installed in an 
available expansion slot, the conflict resolver maintains a record of the current 
resource assignments and generates new resource assignments. Since the 
new manually-configured I/O card is not recognized by the computer 

30 operating system until the computer is re-booted, the conflict resolver 

manages resource assignments for both current boot and the next boot. This 
enables a user to register the resource requirements for manually-configured 
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I/O cards prior to physically Installing the cards in the system. Thus, a user 
can be assured that after a card is inserted and a conflict-free resource 
assignment produced, that the tx>ard will boot up conflict free on the next 
boot. 

5 

Initial Expansion Card Installation 

Refening now to Figure 3, the initial installation of a manual card 336 
into a computer system is disclosed. For the purposes of this discussion, it is 
assumed that the computer system is booted and running. For manual I/O 

10 cards that are essential for booting, it is necessary to have entries in the 
persistent hardware configuration database 304 prior to booting in order to 
invoke the appropriate device drivers and successfully load the operating 
system. Such cards would generally include the motherboard, an output 
device controller, such as a display card, a keyboard or other input device 

15 controller and a boot device controller, such as a disk drive. TTie initial 
database entries for these cards may be created by some low level 
installation utility. Attematrvely, manual cards which are essential for booting 
can be arranged to automatically configure themselves on power up. This 
might be done by setting manually appropriate jumpers or switches on the 

20 cards to produce a non-conflicting set of resource allocations. Since the 
number of cards Is small, the task is feasible. 

For manual I/O cards that are not essential for t>ooting, such as card 
336, entries can be created in the hardware configuration database 304 using 
a computer viewer object 302 which provides to a user a graphical view of the 

25 hardware components in the computer system. Object 302 might, for 
example, be generated by a hardware configuration system such as that 
described in U.S. Patent No. 5,546,595, the contents of which are hereby 
incorporated by reference. 

The computer viewer object 302 instantiates a control panel object 312 

30 which provides a user with a way to change the system configuration. The 
control panel object 312, in tum, instantiates an configuration option retriever 
object 334 and a manual I/O card object 332 as indicated by arrows 317 and 
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318, respectively. The option retriever object 334 retrieves default resource 
assignments from the configuration option database 310 as indicated by 
anrow 316 and provides the defeult resource assignments to the manual I/O 
card object 332 (schematically illustrated by anrow 324.) 

The manual I/O card object 332 registers the resource requirements, 
such as possible assignments, defeult assignment and constraints in 
assignments for the I/O functions on the card with the resolver object 320 as 
indicated by an^ow 330. The manual I/O card object 332 then asks the 
resolver object 320 to produce a resource assignment for each I/O function 
on the card, corresponding to its default jumper settings (when the card is 
initially installed, its jumper settings are generally at the default settings.) 

If the resolver object 320 succeeds in creating a conflict free resource 
assignment set for the I/O functions on the card using their default 
assignments, the installation completes without any user intervention. The 
conflict-free resource set is returned to the manual I/O card object as 
indicated by arrow 328. The manual I/O card object then stores the resource 
requirements for the card in the persistent hardware configuration data base 
304 as indicated by arrow 326. 

If the resources conBsponding to the default jumper settings of the 
card are cunrentiy allocated to an auto-configurable card (such as Plug & Play 
ISA or PCI card) and, if these resources can be re-assigned during the next 
boot operation, the manual I/O card object 332 stores the resource 
requirements for the card In the persistent data base 304. The user is then 
instructed to reboot the system. During reboot, the auto-configurable cards 
are re-configured and resources conresponding to the default jumper settings 
of the card are assigned to the manual I/O card 336. 

Altematively, if the resources conresponding to the default jumper 
settings of the card 336 are cunrentiy allocated to other cards and. if those 
resources can not be re-assigned, user intervention is required in changing 
the jumper settings of the card 336. The resolver object 320 creates a conflict 
object 338 which provides detailed information about tiie conflict such as 
conflicting resource, I/O function witii which tiie card being installed is 
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conflicting and possible conflict free assignments tliat can be used by the 
card 336. The user should manually change the jumper settings of the card 
336 using the infomnation provided by the conflict object 338. When the user 
chooses to change the jumper setting according to the information provided 
5 by the conflict object 338. the manual I/O card object 332 creates an 
appropriate entry for the card 336 in the persistent hardware configuration 
database 304. 

Whenever the manual I/O card object 332 creates an entry in the 
persistent database 304, that entry is associated with a hardware interface 

10 identifier for a connector (typically a defeult connector) on the card 336. 
During subsequent t)oots, the resource requirements are retrieved from the 
persistent data base using the identifier for the connector as a key. 

During installation, the configuration recorder object 314 for a manual 
card that requires a nested recognizer (such as SCSI bus) to be invoked 

15 during boot, is registered with a persistent database called a manual recorder 
registry. The manual recorder registry maintains a collection of manual 
recorders that require nested recognizers to be initiated during boot. After 
completing the steps described in the above paragraphs, the computer viewer 
302 registers the card module with the hardware configuration database 304. 

20 If the card is assigned resources for this boot and if the card's recorder is 
registered with the manual recorder registry for recognition, a nested 
recognizer required by the card Is initiated. 

Figure 4 illustrates the initial installation of an auto-configurable card 
440, such as a plug and play card into the computer system. Again, for 

25 purposes of the discussion, it is assumed that the computer system is booted 
and operational at the time that the card 440 is inserted. 

As with the manual I/O card, the auto-configurable card 440 is installed 
using a computer viewer object 402 which provides to a user a graphical view 
of the hardware components in the computer system. The computer viewer 

30 object 402 instantiates a control panel object 412 which provides a user with 
a way to change the system configuration. The control panel object 412, in 
turn, instantiates a plug and play I/O card object 436 as indicated by arrow 

23 



wo 99/39268 



PCT/US99/0I740 



418. The plug and play I/O card object 436 retrieves default resource 
assignments directly from the card 440 as indicated by am>w 434. 

The plug and play I/O card object 436 registers the resource 
requirements, such as possible assignments, default assignment and 
constraints in assignments for the I/O functions on the card with the resolver 
object 420 as indicated by arrow 430. The plug and play I/O card object 436 
then asks the resolver object 420 to produce a resource assignment for each 
I/O function on the card. 

If the resolver object 420 succeeds in creating a conflict free resource 
assignment set for the I/O functions on the card, the installation completes 
without any user intervention. The conflict-free resource set is returned to the 
plug and play I/O card object 436 as indicated by anrow 428. The plug and 
play I/O card object 436 then programs the card 440 with the conflict free 
resource assignments as indicated by an-ow 432 and stores the resource 
requirements for the card in the persistent hardware configuration data base 
404 as indicated by arrow 426. 

A plug and play I/O card recorder object 414 is also resurrected from 
an object database 406 under control of the computer viewer 402 as 
indicated by anrows 405 and 407. 

Resource Assignnnent on Boot 

Referring rK>w to Figure 5, the operations and objects used during a 
boot up operation of a computer system which includes a manual card 536 or 
a mothertx>drd (not shown in Figure 5) is illustrated. During computer 
booting, the boot system (not shown) instantiates an appropriate card 
recognizer set. The card recognizer set contains card recognizers for all the 
buses in the system, such as motherboard devices, ISA slots, VESA slots, 
PCI slots and PCMCIA sockets. Each card recognizer is responsible for 
determining the expansbn cards on the bus it represents, registering possible 
resource assignments for the functions on each card with the resource 
conflict resolver and for instantiating an appropriate configuration recorder for 
each card. 
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In particular, a manual card I/O recognizer object 542 is instantiated by 
a boot system (not shown) which may be similar to the boot system described 
in U.S. Patent No. 5.379.431. the disclosure of which is incorporated herein 
by reference. As discussed in detail below, the recognizer object 542 is 
instantiated from a subclass which has been tailored for card 536 from more 
general classes which are part of a recognizer framework that is designed to 
obtain infonmation from various cards. The subclass might, for example, be 
generated by the card manufacturer. 

During the system boot operation, the card recognizer object 542 
identifies each of the manual I/O cards coupled to the system bus. The boot 
system also instantiates an appropriate mothert>oard configuration recognizer 
(294. Figure 2) that represents a specific motherboard. Since the manual 
cards and the mothert)oard do not have on-board storage for resource 
requirements, the recognizer objects 294 and 542 retrieve resource 
requirements for the motherboard and each manual card 536 from the 
hardware configuration database 504. Resource requirements in the 
hardware configuration database 504 can be generated by a hardware 
configuration management system using a computer viewer as descrit>ed 
above when the card is installed. Alternatively, the resource requirements 
can be entered by the user directly, or obtained from the card itself. 

The manual I/O card recognizer object 542 receives the current 
resource assignment and ranges of the manual card 536 as indicated by 
anpw 534 and provides the current resource assignments and ranges to the 
resource conflict resdver object 520 as indicated schematically by arrow 530. 

If the resource conflict resolver object 520 identifies a resource conflict, 
then resolver object 520 instantiates a conflict object 478 which notifies a user 
of the resource conflict and provides to the user an indication of potential 
solutions (i.e. conflict free resource assignments.) Altematively, if resolver 
object 520 detemiines that no resource conflicts exist, then resoh^er object 
520 returns to recognizer object 542 the conflict free resource assignments 
for the manual card 536 as indicated by arrow 528. 
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The conflict free resource assignments are then encapsulated in a 
manual card I/O recorder object 514 instantiated by the recognizer object 542 
and a corresponding motherboard recorder object instantiated by the 
motherboard recognizer. As indicated in Figure 5, the recorder objects are 
instantiated by a service which resurrects the objects from a database 506 
using an identifier derived from a unique card ID. Object database 506 is 
persistent in the memory of the computer system which includes the resource 
conflict resolver object 520. Configuration recorder objects are instantiated 
using a service that resun-ects the appropriate object using an identifier based 
on the board ID and the motherboard type as indicated by annows 505 and 
507. In the case of the motherboard the recorder creates a manual I/O card 
representing the motherboard and a collection of manual I/O function 
resource objects for the functions on the motherboard. 

Recognizer object 542 then uses a method in the recorder object 514 
to record the current resource assignments in the hardware configuration 
database 504. 

Referring now to Figure 6, the operations and objects used during a 
boot of a computer which includes a plug and play card 640 are shown. As 
with the manual I/O cards, a plug and play I/O card recognizer object 642 is 
instantiated by a boot system (not shown.) As discussed in detail below, the 
recognizer object 642 is instantiated from a subclass which has been tailored 
for card 640 from more general classes which are part of a recognizer 
framework that is designed to obtain infonmation from various cards. The 
subdass might for example, be generated by the card manufacturer. 

For configurable cards, each recognizer is also responsible for 
configuring the cards with conflict free resource assignments. The possible 
resource assignments for plug and play cards are retrieved from the cards 
themselves. In particular, plug and play I/O card recognizer object 642 
retrieves from plug and play card 640 cun^ent resource assignments and 
ranges for plug and play card 640. Such current resource assignments and 
ranges can be retrieved from a memory (not shown) which is mounted on 
card 640 as scheniaticaliy indicated by arrow 634. 
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The current resource assignments and ranges are fed from recognizer 
object 642 to a resource conflict resolver object 620 as indicated by arrow 
630. Other recognizer objects (not shown) also retrieve infonmation from 
other cards (not shown) which are present at boot up. As discussed in detail 
bebw, resource conflict resolver object 620 examines the resource 
assignments and ranges fed thereto and then takes one of two actions. If 
resolver object 620 determines that a conflict between the resource 
assignments and ranges of card 640 exists with other system resources, then 
resolver object 620 instantiates a conflict object 650 which indicates that a 
conflict exists and the nature of the conflict. The conflict object 650 may 
include information such as an identity of the conflicting resources, a 
conflicting period, an identity of conflicting I/O functions, etc. 

If, however, resolver object 620 can generate a conflict-free 
assignment of resources and, accordingly, the resources and ranges 
assigned to card 640 do not produce any conflicts with other resource 
assignments and ranges of the other cards in the system, resolver object 620 
generates a set of conflict free resource assignments and retums the conflict 
free resource assignments for card 640 to recognizer object 642 as indicated 
by annow 628. Recognizer object 642 then "programs" card 640 by causing 
the resource assignment infomnation to be stored in a memory of the card 
640, for example as illustrated by arrow 644. 

The plug and play card recognizer 642 also instantiates an appropriate 
plug and play card configuration recorder object 614 for each plug and play 
card kientified. Configuration recorder object 614 is also instantiated using a 
service that resunrects an appropriate object from objects stored in object 
database 606 using an identifier derived frrom a unique card ID. Card 
recorder object 614 is responsible for registering card 640 in the hardware 
configuration database 604 and also recording the configuration information 
in the database. 

As described below, recognizer object 642, conflict resolver object 620, 
conflict object 650 and recorder object 614 may all t>e provided from classes 
similar to the classes to be described below in conjunction with Figures 7-18. 
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Figures 7-18 are a series of so-called Booch diagrams illustrating classes 
which form a variety of different frameworks. Each of the classes and the 
relationships therebetween will be discussed in detail below. The Booch 
diagrams and notations used therein are well known to those of ordinary skill 
5 in the art and will not be descrit)ed or explained herein. The interpretation of 
the Booch diagrams and notations are explained in a text book published by 
The Benjamin/Cummings Publishing Company, Inc. entitled Object-Oriented 
Analysis and Design with Applications by Grady Booch which is hereby 
incorporated herein by reference. 

10 

Conflict Resolver Framework Classes 
1. The Exoansion Bus Framework 

Figures 7-9 illustrate the composition and interrelations of a set of 
classes which form an expansion bus framework. The expansion bus 

15 framework is provided from a set of classes which represent the general 
behavior of a variety of different expansbn buses. For a specific type of 
expansion bus, a specific set of subclasses are derived from the classes 
provided: by the expansion bus framework. The expansion bus frameworic 
thus provides a common model for recognizing expansion cards, detenmining 

20 the i/O functions on expansbn cards, registering the resource requirements 
of the I/O functions on the expansbn cards and instantiating configuration 
recorder objects for each of the expansion cards on various expansbn buses. 

Refemng now to Figure 7. the expansion bus framework is shown to 
include a base dass 700 named TIOCardRecognizer. The 

25 TIOCardRecognizer dass 700 is an abstract base class which indudes 
member functbns (illustrated in the box shown next to object 700) which 
represent the general t>ehavior of recognizer objects. The memt>er functions 
are illustrated as pure virtual functions which means that they must be 
overridden in the derived subdasses. Thus, for each particular type of 

30 expansion bus, a particular recognizer sut)class will be derived from the 
TIOCardRecognizer dass 100 and a corresponding recognizer object for a 
specific expansion bus will be instantiated from the derived recognizer class. 
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In the derived subclasses the pure virtual functions of the abstract base class 
will be ovenidden. 

The TIOCardRecognizer dass 700 includes the typical constructor and 
destructor member functions as well as a plurality of unique member 
5 functions. For example, the TIOCardRecognizer class 700 includes a method 
called SetSlotldentifiers which can be called to create 
THardwarelnterfaceldentifier objects for each of the slots on the expansion 
bus for which a particular recognizer object is responsible. The method has 
the form: 

10 

void SetSlotldentifiers (THardwareModuleMaker& parentDevice, const 

THardwarelnterfaceldentifier& parentlnterface, 
const short baseSiotlndex, const short 
slotCount) = 0; 

15 

The SetSlotldentifiers method also adds the 
THardwarelnterfeiceldentifier objects to a THardwareModuleMaker object 
which describes the hardware on the bus! The SetSlotldentifiers method is 
also called by a mothert>oard configuration recorder object during 

20 mottierboard installation to identify slots on the motherboard. 

The TIOCardRecognizer dass 700 also indudes a method called 
RegisterPossibleAssignments. This metiiod is called to register defeuit, or 
possible, resource requirements with the resource conflict resolver object. 
Such resource requirements include, but are not limited to, the possible 

25 resource assignments arul constraints in resource assignments for multiple 
I/O functions on all expansion cards on a particular bus. For auto- 
configurable expansion cards, possible resource assignments are obtained 
from the expansion cards and constraints in resource assignments are 
obtained from an I/O function constraint registry. For manually-configured 

30 cards, resource requirements {both possible resource assignments and 

constraints in resource assignments) are obtained from a persistent hardware 
configuration database as described above. The method has the form: 
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void RegisterPossibleAssignments (const THardwareModuleHandle& parent, 

TIOResourceConflictResolverHandle 
& resolver) = 0; 

The TIOCardRecognizer class 700 also includes a method called 
InstantiateCardRecorders. This method is called by a card recognizer during 
a boot operation to instantiate an appropriate configuration recorder object for 
each auto-configurable expansion card in a computer system. It has the 
form: 

void InstantiateCardRecorders (const THardwareModuleHandle& parent. 

const TIOResourceConflictResolverHandle& resolver. 
const THardwareinterfeceldentifier& parentlnterface. 
const TintenruptHandlerReference& parentHandler) = 0; 

For auto-configurable buses, the InstantiateCardRecorders method 
retrieves conflict-free resource assignments from the resource conflict 
resolver object for the I/O functions on each expansion card coupled to the 
bus and programs the expansion card accordingly. The method also 
resurrects and invoices the conresponding configuration recorder object for 
each recognized card on the bus. 

The recognizer object creates an appropriate 
THardwarelnterfaceldentifier object for each edge electrical connector on the 
expansion card and passes the edge connector identifier object to the 
configuration recorder object. The InstantiateCardRecorders method also 
obtains a hardware card module from each configuration recorder object and 
registers the card module in the aforementioned computer hardware 
configuration database to represent the hardware on the bus. The 
recognizer retrieves the appropriate slot Identifier from the card module and 
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provides it to the appropriate configuration recorder object so that the 
configuration recorder object can modify the stored bus card module 
appropriately. 

The InstantiateCardRecorders method also creates a 
THardwareModuleMaker object that represents "software-impaired" cards 
(cards which are not auto-configurable), registers such software-impaired 
cards with the computer hardware configuration database and spawns a new 
thread that waits for a conresponding configuration recorder object for a 
software-impaired card to become available in the system. For manually- 
configured buses the InstantiateCardRecorders method is not used. 

Possible subclasses derived from the TIOCardRecognizer base class 
700 include a ManuallOCardRecognizer class 702, a 
TPIugNPIaylSACardRecognizer class 704, a TPCICardRecognizer class 706 
and a TElSACardRecognizer class 708. From each of these subclasses, 
recognizer objects for conresponding types of expansion buses can be 
instantiated. 

A recognizer object is an object having data attributes and member 
functions (SetSlotldentifiers) which allow the recognizer object to identify, for 
a particular type of expansion bus, the expansion slots into which expansion 
cards are coupled. The member functions also provide a means for 
registering possit>le resource assignments of the expansion cards with the I/O 
conflict resolver object (RegisteriPossibleAssignments) and means for 
instantiating card recorder objects (InstantiateCardRecorders.) 

The TPIugNPIaylSACardRecognizer class 704 is one example of a 
subclass derived from the abstract TIOCardRecognizer base class 700. As 
explained above, an expansion card which confonms to the Plug-and-Play ISA 
standard is auto-configurable. A recognizer object for an auto-configurable 
bus Valks" the conresponding bus, in order to recognize each auto- 
configurable expansion card coupled to the bus, retrieves the resource 
requirements for the I/O functions on each auto-configurable expansion card 
and registers the resource requirements with a resource conflict resolver. 
The actual functions performed during the search on the bus for auto- 
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configurable cards is dependent on the bus hardware. However, the bus will 
be searched in a predetermined order to insure that all expansion cards on 
the bus are located and examined. 

The recognizer object for an auto-configurable bus also instantiates an 
5 appropriate configuration recorder object for the auto-configurable expansion 
card, which configuration recorder object stores the respective conflict-free 
resource assignments computed by a resource conflict resolver coupled to 
the bus. The recognizer object is further responsible for creating 
THardwarelnterfaceldentifier objects which characterize each of the 

10 expansion bus slots and adding them to the motherboard module during the 
installation of the motherboard. 

The TManuall/OCardRecognizer class 702 is another example of a 
possible subclass of the TIOCardRecognizer base class 700. An instance of 
the TManuall/OCardRecognizer class 702 is a Manuall/OCardRecognizer 

15 object which is a recognizer object for a manually-configured I/O expansion 
card. When a manually-configured I/O expansbn card is coupled to a bus, 
the Manuall/OCardRecognizer object makes an entry for the manually- 
configured I/O expansion card in the hardware configuration database. 

A recognizer object for a manually configurable bus also Valks" each 

20 expanston bus and retrieves the resource requirements for the I/O functions 
on the manually-configured I/O expansion cards on the bus from a persistent 
hardware configuration database and registers the resource requirements 
with a resource conflict resolver object. The recognizers for an indivWual 
expansion bus are mononrorphic and nonnally will not be subclassed by 

25 devetopers. 

Referring now to Figure 8, the expansion bus framework also includes 
an object dass 800 named TConfigurationOptionRetriever. The 
TConfigurationOptionRetriever class 800 is an abstract base dass which 
defines a protocol for retrieving resource requirements from the 
30 aforementioned persistent configuration option database. Such resource 
requirements may indude, but are not limited to. possible resource 
assignment sets and constraints in resource assignments for multiple I/O 
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functions on expansion cards and the mothertx>ard. Thus, for each particular 
type of expansion bus coupled to the computer system, a specific option 
retriever dass will be derived from the TConfigurationOptionRetriever dass 
and a corresponding retriever object will be instantiated from the derived 
5 class. 

For example, in a computer system which indudes both an EISA 
expansion bus and a manually-configured expansion bus. a 
TElSAConfigurationOptionRetriever dass 804 and a 
TManualConfigurationOptionRetriever dass 808 are derived from the 

10 TConfigurationOptionRetriever dass 800. From these two derived classes 
804, 808, con-esponding retriever objects can be instantiated to retrieve 
function information on each i/O function on each of the respective cards as 
well as vendor specific infomiation for respective EISA and manually- 
configured expansion cards. 

15 The TConfigurationOptionRetiiever dass 800 includes the typical 

constructor and destiuctor memt>er functions as well as a plurality of unique 
member functions which are pure virtual functions and, thus, will be 
overridden by derived dasses. For example, the 

TConfigurationOptionRetriever class 800 indudes a member function called 

20 GetPossibleAssignrnentsO which intenrogates the configuration option 

database and retunns possible resource assignment sets for an individual I/O 

function on an expansion card. A second member function called 

GetDefaultAssignmentsO retums a default resource assignment for an 

individual I/O function which corresponds to a factory setting of the expansion 

25 card. A GetFunctionlnformationO nrtethod retums the function information for 

an individual i/O function on the expansion card. A GetFunctionCount() 

method retums the number of I/O functions on the expansion card. The 

dass definition is as follows: 

class TConfigurationOptionRetriever 
30 { 

public- 
virtual -TConfigurationOptionRetriever (); // Destructor 
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// Streaming operators 

II 

virtual TStream& operator »= (TStream& toWhere) const; 
virtual TStream& operator «= (TStream& fromWhere); 

5 

typedef unsigned int FunctionCount; 
virtual FunctionCount GetFunctionCount() const = 0; 
virtual void GetFunctionlnfonnation 

(const TiOFunctioniHardwarelnterfaceldentifier.: 
10 FunctlonNumber functionNumber, 

TIOFunctionlnformation& function) const = 0; 

virtual void GetPossibleAssignments 

(const TIOFunctionHardwarelnterfaceidentifien: 
15 FunctionNumberfunctionNumber, 

TCollectionOf <TPossiblelOResourceAssignment>& 
possibles) const = 0; 

virtual void GetDefauttAssignment 
20 (const TIOFunctionlHardwareinterfaceldentifier:: 

FunctionNumber functionNumber, 
TCollectionOf <TPosstblelOResourceAsslgnment>& 
default) const = 0; 

25 virtual void GetVendorlnfonmatton (TText& vendor) const = 0; 

virtual void SetModuleSignature (const THardwareModuleHandle:: 

HardwareModuleSignature& card ); 

30 protected: 

TConfigurationOptionRetriever (const THardwareModuleHandle:: 

HardwareModuleSignature& card); 
TConfigurationOptionRetriever (); 
TConfigurationOptionRetriever (const 
35 TConfigurationOptionRetriever& copy); 

TConfigurationOptionRetriever& operator = (const 

TConfigurationOptionRetriever& right); 

40 private: 

TStandardText fModule; 

}: 
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A ConfigurationOptionRetriever object also contains a 
SetModuleSignature method which stores a module signature which is a 
unique hardware ID for the corresponding card in the corresponding hardware 
module object representing the card. Similarly, a GetVendorlnfo method 
retrieves vendor specific information from the expansion card and writes it to 
a vendor text object referenced in the object. 

A TIOFunctionlnformation class 802 is associated with the 
TConfigurationOptionRetriever class 800. The TlOFunctionlnfonrnatfon class 
is a base class that encapsulates bus specific information about f/O functions 
on a card, such as function number, function type, etc.... For a particular type 
of card, a particular function information class can be derived from 
TIOFunctionlnfonmation class 802. 

For example, as shown in Figure 9, a plurality of exemplary function 
information classes 902-908 are shown derived from the 
TIOFunctionlnformation class 900. Each of the derived classes include 
infomnation for I/O functions on one particular type of card. For example, a 
TPIugNPIaylSAFunctionlnfonnation dass 904 is provided having bus specific 
infomiation about a particular I/O function on an expansion card conforming 
to the Plug and Play ISA standard. Similariy, the TPCIFunctionlnformation 
and TElSAFunctionlnfonmation classes 906, 908 each include bus specific 
information aboxA particular I/O functions on expansion cards conforming to 
the PCI and EISA standards, respectively. TManuallOFuncBonlnfomiation 
dass 902 is also shown derived from the TIOFunctionlnformation base dass 
900. The TManuailOFunctionlnformation dass 902 encapsulates I/O function 
infomiation on nnanually-configurable boards. 

Returning now to Figure 8. a TPossibleResourceAssignment dass 806 
is also assodated with the TConfigurationOptionRetriever dass 800. The 
TPossibleResourceAssignment dass 806 encapsulates both possible 
resource assignments and default (factory-assigned) resource assignments. 
As Indicated in Figure 8, for each Instance of TConfigurationOptionRetriever 
there may be one or more TPossibleResourceAssignment objects 
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instantiated, each containing a possible resource assignment set A single 
default resource assignment set is associated with one instance. 

Referring now to Figure 10, the expansion bus framework further 
includes a dass 1000 named TIOFuncttonConstraintRegistry. The 
TIOFunctionConstraintRegistry dass 1000 encapsulates constraints on 
resource assignments for I/O functions on auto-configurable expansion cards, 
such as Plug & Play ISA and PC! expansion cards. Constraints express limits 
on assigning resources. The TIOFUNCTIONCONSTRAINTREGISTRY object 
are stored in a persistent database (not shown). The 
TIOFunctionConstraintRegistry dass 1000 indudes typical construction and 
destructor member functions as well as a WartForChange() member function 
which waits for any change in the I/O function constraints registered in the 
function constraint registry database. 

A TIOFunctionConstraint dass 1004 is associated with the 
TIOFunctionConstraintRegistry dass 1000. The TIOFunctionConstraint dass 
1004 encapsulates information about a constraint on resource assignments 
for an I/O function. The information which is encapsulated depends on the I/O 
function. 

The TIOFunctionConstraint dass 1004 also indudes typical constructor 
and destructor member functions as well as a plurality of attributes which 
encapsulate constraint information. For example, the TIOFunctionConstraint 
dass 1004 indudes a CardEdge attribute which holds a reference 
THardwareinterfeceldentifier object that identifies a card edge connector. A 
Function attribute holds a FunctionNumber that uniquely identifies one among 
a number of functions on the board. Finally, a Constraint attribute holds a 
reference to a TPossibleResourceAssignment object which specifies that 
actual constraints. The dass definition is as follows: 

class TIOFunctionConstraint 

{ 

public: 

TIOFunctionConstraint (); 
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TIOFunctionConstraint (const TIOFunctionConstraint& copy); 
TIOFunctionConstraint& operator= (const TIOFunctionConstraint& 

right); 

virtual -TIOFunctionConstraint (); //Destaictor 
// Streaming operators 

// 

virtual TStream& operator »= (TStream& toWhere) const; 
virtual TStream& operator «= (TStream& fromWhere); 

virtual THardwarelnterfaceldentifier* CopyEdgeldentifier () const; 
virtual void SetEdgeldentifier (const THardwarelnterfaceldentifier& 

edgelD); 

virtual TIOFunctionHardwarelnterfaceldentifien:FunctionNumber 

GetFunctionNumber () const; 

virtual void SetFunctionNumt)er 

(const TIOFunctionHardwarelnterfaceldentifien: 
FunctionNumber functionNumt}er); 

virtual void GetAssignmentConstraint( 

TPossiblelOResourceAssignment& constraint) 
const; 

virtual void SetAssignmentConstraint ( 

const TPossiblelOResourceAssignment& 
constraint); 

enum EGarbageCoilect {ItGarbageCollection. 

kNoGarbageCollection}; 

virtual EgarbageCollect GetGarbageCollectionStatus () const; 
virtual void SetGarbageCollectionStatus (const 



TIOFunctionHardwarelnteifaceldentifier:FunctionNumber 
fFunctionNumber, 

EgarbageCollect fGarbageCollect; // for PCMCIA=FALSE 



EgarbageCollect status); 



private: 



THardwarelnterfaceldentifier* 
TPossiblelOResourceAssignment 



fEdgelO; 
fConstraint; 
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The expansion bus framework also includes a 
TconfigurationRecorderLocator template class 1002. All individual bus 
frameworks use this class and an indivkiual bus framework uses a 
CreateConfigurationRecorder() member function of this dass to resurrect the 
5 appropriate configuration recorder object for an expansion card. The class 
definition is as follows: 

template <class AconfigurationRecorder> 
class TconfigurationRecorderLocator 
10 { 

public: 

TconfigurationRecorderLocator(const Ttext& theRecorderiD); 
virtual -Tconfiguratk)nRecorderLocator(); 

15 virtual AconfigurationRecorder^ CreateConfigurationRecorder 

(Boolean WaitForRecorder); 

}: 

2. The Conflict Resolver Framework 

20 Figures 11-13 illustrate a set of classes which forni a conflict resolver 

framework. The conflict resolver framework is provided from a set of classes 
which provide a bus independent model for detecting and resolving conflicts 
in resource usage which arise between multiple I/O functions on the 
expansion cards and motheri[)oard of the computer. 

25 A plurality of classes in the I/O conflict resolver framewortc are 

discussed in detail in conjunction with Figures 11-13. In general overview, 
however, the conflict resolver framework includes an abstract class named 
TIOResourceConflictResolver which creates an object that manages the 
assignment of I/O resources (such as I/O registers, I/O memory, intenrupt 

30 signal lines, interrupt levels and DMA channels) to I/O functions on the 
motherboard and expansion cards. 

The resource conflict resolver object interacts with several card usage 
classes that are stored in the hardware configuration database and 
encapsulate resource infonnation for a card and functions on the card. This 

35 resource informatton includes possible resource assignments sets, constraint 



38 



wo 99/39268 



PCTAJS99/01740 



information and conflict-free resource assignments made by the resource 
conflict resolver object Such resource assignments information may, for 
example conrespond to possible resource assignments, constraints in 
resource assignment, conflict-free resource assignnrient and the resource 
5 conflict information (whenever a conflict is encountered). The 

TIOCardResourceUsage class encapsulates resource usage and conflict-free 
resource assignments made by the resource conflict resolver object for all I/O 
functions on a card. The resource conflict resolver class is also associated 
with a TIOFunctionResourceUsage class which encapsulates the resource 
10 usage information for an individual I/O function. 

In general, the resource conflict resolver object deals with four 
resources: memory, I/O registers, DMA channels and interrupt sockets. A 
TIOMemoryUsageMode class encapsulates characteristics of the memory 
range; a TInterruptUsageMode class encapsulates characteristics of an 
15 intenupt socket and a TDMAUsageMode dass encapsulates characteristics 
of a DMA channel. 

In accordance with one aspect of the invention, the 
TIOFunctionResourceUsage class is associated with a 
TIOResourceLockEntry dass which manages access to the system resources 

20 assigned to an I/O function and encapsulated in an 

lOFunctionResourceUsage object. As will hereinafter be explained, a 
lOResourceLockEntry object contains a semaphore which must be acquired 
by a dient, such as a device driver, which wishes to obtain access to the 
resource assignments and then to the assigned resources. 

25 The TIOFunctionResourceUsage dass is also associated with a 

TIOResourceConflict dass. The TIOResourceConflict class encapsulates the 
infonmation about a resource conflict whenever a conflict is encountered in 
the resource assignment for a particular I/O function. Objects instantiated 
from the TIOResourceConflict dass indude infomnation explaining why a 

30 particular I/O function could not be assigned the required resource and what 
other I/O functions are involved in the resource conflict. 
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Possible resource assignment sets and constraints on those 
assignments are encapsulated in several other objects. A 
TPosslblelOFunctionResourceAsstgnment class contains information 
representing choices and constraints in system resource assignment for an 
5 individual I/O function. A TIOMenK)ryConstraint is the representation of 
constraints on memory ranges required by an I/O function. A 
TIORegisterConstraint is the representation of a I/O register range required 
by an I/O function and the constraints on that range. A TInterruptConstraint is 
the representation of an intermpt socket required by an I/O function and the 

10 constraints on that socket. A TDMAConstraint is the representation of a DMA 
channel required by an I/O function and the constraints on that channel. 

The TIOFunctionResourceUsage class is further associated with 
several classes which encapsulate the conflict-free resource assignments 
generated by the resource conflict resolver object and are referred to by the 

15 resource usage objects. For example* a TIOFunctionResourceAssignment 
class is used by the resource conflict resolver object to represent a conflict- 
free resource assignment for an individual I/O function. A 
TIOMemoryAssignment class contains information representing a memory 
range assigned to the I/O function. A TIORegisterAssignment class contains 

20 information representing an I/O register range assigned to an I/O function. A 
TInterruptAssignment dass is the representation of interrupt sockets assigned 
to an I/O function. A TDMAAssignment dass is the representation of a DMA 
channel assigned to an I/O function. 

Referring now to Figure 1 1 , a conflict resolver framework indudes a 

25 TIOResourceConflk:tResolver dass 1 100 which indudes constructor and 
destructor member functions as well as a plurality of unique memt>er 
functions. The constructor creates a single reference-counted master object 
by lazy evaluation (the first client to require the conflict resolver creates it by 
calling the constructor.) The destructor destroys the object if the reference 

30 count is zero. The TIOResourceConflictResolver class is a monomorphic 
dass and is normally not subdassed by developers. 
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Clients of the resource conflict resolver object execute a 
GetSystemResourceConflictResolverO method which returns a handle to the 
system conflict resolver object so that they can communicate with the object. 
The handle provides a streamlined and simple representation of the resolver 
object which representation is easy to copy and stream. 

The TIOResourceConflictResolver class 1 100 also includes a 
RegisterPossibleAssignmentsO method which registers the possible resource 
assignments for all I/O functions on an expansion card or a motherboard. 
The possible resource assignments are encapsulated in a resource usage 
object generated by a recognizer or card object. Registration occurs by 
adding the card to a deque of card resource usage objects in the resource 
conflict resolver object. The code for the function follows: 

void TIOResourceConflictResolver iRegisterPossibleAssignments 



slotiD = card.CopySlotldentifier(); 
// Attempt to find the existing card 
if ((cardToRegister = FindCardBylDCslotID)) == NIL) { 

cardToRegister = new TIOCardResourceUsage(card); 

cardToRegister->SetSlotldentifier(*slotlD); 

fCard.Add(cardToRegister); 



else { 

card.GetFunctionResourceUsage(newUsage); 
cardToRegister->SetFunctionResourceUsage(newUsage); 



(const TIOCardResourceUsage & card) 



TIOCardResourceUsage 

THardwarelnterfaceldentifier 

TDequeOf<TIOFunctionResourceUsage> 



^cardToRegister; 
*slotlD; 



newUsage; 
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newUsage.DeleteAIIO; 

} 

} 

Possible resource assignments for each I/O function must be 
determined prior to a call to this method. Clients of the resource conflict 
resolver such as the motherboard recorder, card recognizers and card 
viewers, register resource requirements such as possible resource 
assignments and constraints on the resource assignments for the I/O 
functions on the motherlDoard and expansion cards with the resource conflict 
resolver object by calling this method. Resource requirements are registered 
with the resource conflict resolver object on a card basis 
(TIOCardResourceUsage) using a slot identifier (SlotID) for the card as a key. 

In response to a call to the method ProduceConflictFreeAsslgnments(), 
the resource conflict resolver object creates a conflict-free resource 
assignment (encapsulated in a TIOFunctionResourceAssignment object) for 
each I/O function on each expansion card, in some instances, it may be 
preferable for an I/O resource assignment to take effect during the present 
boot operation. ARematively, it may be preferable for an I/O resource 
assignment to take effect during the next subsequent boot operatbn. Thus, a 
boot period is specified by the dient, whteh boot period indicates if a resource 
assignment for an I/O functk)n is valid for the present boot operation or for the 
next subsequent boot operation. 

If the resource conflict resolver object encounters a resource conflict 
while creating a resource assignment for a particular I/O function, then the 
resource conflict resolver also creates a TIOResourceConflict object for that 
particular I/O function and continues to try different resource combinations in 
order to obtain a conflict-free resource assignment. A TIOResourceConflict 
object encapsulates information, such as which system resource is involved 
in the conflict, the period of time during which the conflict exists, what the 
conflicting I/O fonctions are, etc. If a conflict-free resource assignment is 
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subsequently produced for the I/O function, the resource conflict resolver 
object deletes the resource conflict object, othenvise an exception is thrown. 

The resource conflict resolver object acts as a centralized source for 
resource allocation infonmation for all I/O functions in the computer system. = 
Clients of the resource conflict resolver object, such as card recognizers, 
access the resource allocation infomiation for an I/O function using a 
THardwarelnterfaceldentifier for the I/O function as a key into the hardware 
configuration database where the information is stored. The resource conflict 
resolver object also includes access control mechanisms to synchronize 
access to the stored resource allocation information by multiple clients to the 
resource assignment computed by the resource conflict resolver object. 

For example, in accordance with the principles of the invention, device 
driver clients of the resource conflict resolver object retrieve resource 
assignments for I/O functions through a semaphore lock encapsulated in an 
lOResourceLockEntry object which is instantiated from a 
TIOResourceLockEntry class 1106. The TIOResourceLockEntryClass 1106 
will be discussed in detail further below. Suffice it here, however, to say that 
device driver clients must instantiate a TIOResourceLockEntry object and 
acquire the lock for the resources by invoking an Acquire() method of the 
lOResourceLockEntry object. After acquiring the lock, device drivers can 
access the actual resource assignments for the corresponding I/O function by 
calling a GetResourceAssignment() method of the lOResourceLockEntry 
object. Since resource assignments can be entered into the hardware 
configuration database by means of the computer viewer, as described 
above, before a card is physically inserted into the computer system, the 
resource conflict resolver object can generate and return I/O function 
resource assignments for the I/O functions on the card even if the card is not 
physically installed. Consequently, the appropriate device driver must verify 
whether the device for which the resource assignment is made is in the 
computer system. 

The TIOResourceConflictResolver class provides methods 
(RemoveCardResourceUsageO; RenrK)veFunctionAssignment(); 
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RemoveFunctionResourceUsageO) to remove the resource assignments on 
an I/O function basis as well as on an expansion card basis when the 
assignments are no longer valid (for example when a new card is added and 
a conflict-free resource assignment cannot be made.) 

The TIOResourceConflictResolver class 1 100 also includes a 
SetFunctionAssignmentConstralntsO method which registers constraints in 
the resource assignment for an I/O function on an expansion card with the 
conflict resolver object. The SetFunctbnAssignmentConstraints() method is 
used by clients of the resource conflict resolver object to force the resource 
assignment for a particular I/O function to a specific value. The constraints in 
resource assignment must not be in conflict with the possible resource 
assignments for the card. If there is any conflict between the constraints, this 
method throws an exception. This method also throws exception if the card 
or the function is not registered with the resolver. 

A RemoveFunctionAssignmentConstraintsO method removes the 
resource assignnnent constraints associated with an I/O function set with the 
aforementioned SetFunctionAssignmentConstraints() method. This method 
throws an exception if the card or the function is not registered with the 
conflict resohrer object 

A GetCardResourceUsageO method of the 
TiOResourceConflictResohfer is called to get conflict-free resource 
assignments for all I/O functions on an expansion card identified by the slotlD. 
The conflict-free resource assignments are created by a prior call to the 
ProduceConflictFreeAssignmentsO method. The GetCardResourceUsageO 
method throws exception if an expansion card is not registered with the 
resource conflict resolver object. The code for this method is illustrated 
below. 

void TIOResourceConflictResolven:GetCanjResourceUsage ( 

const THardwarelnterfaceldentifier & slotID, 
TIOCardResourceUsage & cardAssignments) 

{ 
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TIOCardResourceUsage *card; 
if ((card = FindCardBylD(slotlD)) NILK 
throw (TconflictResolverException 

(TConfiictResolverException::kCardNotRegistered) 

); 

return; 

} 

cardAssignments = *card; // Copy stuff over 

} 

TIOCardResourceUsage * TIOResourceConflictResolveniFindCardBylD 

(const THardwarelnterfaceldentifier & slotID) 
const 

{ 

TIOCardResourceUsage *card; 
THardwarelnterfaceldentifier ^checkid; 
TlteratorOver<TIOCardResourceUsage> iterator, 

iterator - fCard.Createlterator(); 

card = iterator->First(); 

while (card 1= NIL){ 

checkid = card->CopySlotldentifier(); 
iff(*checkid==stotlD){ 

delete checkkl; 

delete iterator; 

return card; 

} 

card = iterator->Next(); 
delete checkid; 
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) 

delete iterator 
return NIL; 

5 } 

A RemoveCardResourceUsage method of the 
TIOResourceConlfictResolverClass 1 100 is called to remove all resource 
assignments (TIOCardResourceUsage) for a particular expansion card. This 
10 method is typically called when an expansion card Is removed from the 
computer system and generates an exception if the expansion card is using 
the resources when the card is being removed. The code for this method is 
as follows: 



1 5 void TIOResourceConflictResolver :RemoveCardResourceUsage(const 

THardwarelnterfaceldentifier & slotID) 

{ 

TIOCardResourceUsage ^cardToRemove; 
TDequeOf<TIOFunctionResourceUsage> funcDeque; 
20 TSequenceOflterator<TIOFunctionResourceUsage> *funclteraton 

TIOFunctionResourceUsage ^funcUsage; 



Iff ((cardToRemove = FindCardBylD(slotlD)) == NIL) { 
throw (TconflictResoiverException 
25 (TConflictResolverException::kCardNotRegistered)); 
return; 

} 

fCard.Remove(*cardToRemove); // Remove card 

} 

30 

A GetFunctionAssignmentO method is called by the recognizers and 
computer viewer control panels only and returns a conflict-free resource 
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assignment for a particular I/O function on a particular expansion card. The 
code for this method is given below: 

void TIOResourceConflictResolver:GetFunctionAsslgnment( 

const TIOFunctionHardwarelnterfaceldentifier& functionlD. 
TIOFunctionResourceAssignment& function) const 

{ 

TIOFunctionResourceUsage *functionltem; 

If ((functionltem = FindFunctionBylD (functionlD)) == NIL) { 

throw (TconflictResolverException 

(TConflictResolverException::kFunctionNotRegistered)); 

return; 



Iff (functionitem->GetAssignment(function) == 

TIOFunctionResourceUsage::kNotAssigned 

){ 

TDequeOf <TIOResourceConflict> conflicts; 

functionltem->GetResourceConflicts(conflicts); 

iff(conflicts.Count()) 

throw (TconflictResolverException 
(TConflictResolverException::kConflictlnResources)); 

else 

throw (TconflictResolverException 
(TConflictResolverException::kNoAssignmentCreated)); 
return; 

} 

} 



47 



wo 99/39268 



PCT/US99/01740 



TIOFunctionResourceUsage * 

TIOResourceConflictResolven:FlndFunctlonBylD(const 

TIOFuncBonHardwarelnterfaceldentifier & functionID) const 

{ 

TSequenceOflterator<TIOCarclResourceUsage> *cardlteraton 

TIOCardResourceUsage *card; 

TDequeOf<TIOFunctionResourceUsage> functionDeque; 

TSequenceOflterator<TIOFunctionResourceUsage> *functionlterator; 

TIOFunctionResourceUsage *functionUsage; 

THardwarelnterfaceldentifier *slotlD, 

*checklD, 
*edgelD; 

TIOFunctionHardwarelnterfaceldentifierrFunctionNumber 

functionNumber; 

functionNumber = funclionlD.GetlOFunctbn(); 

// Find the slot ID fronfi the function ID by navigating through the HW 
Config DB 

If ((edgelD = functtonlD.CopyParent()) == NIL) 
return NIL; 

THardwareConfigurationHandle myOB; 

myDB = THardwareConfigurationHandle::GetComputerDatabase(); 
THardwareinterfaceHandle edgeHandle = 

myDB.Getlnterface(*edgelD); 

TDequeOf <THardwareConnectionHandle> nnyConnections; 
edgeHandle.GetAIIConnections(myConnections); 
THardwareConnecUonHandle* edgeConnectlon = 
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myConnections.First(); 

THardwarelnterfiaceHandie slotHandie = 

edgeConnection->GetOtherEnd (edgeHandle); 
slotID = stotHandle.CopyHardwarelnterfaceldentifier(): 

myConnections.DeleteAII(); 

If (slotID == NIL) 
return NIL; 

cardlterator = fCard.CreateSequencelterator(): 
card = cardlterator->Flrst(): 

while (card != NIL) { 

checkID = card->CopyStotldentifier(); 
If CchecklD N'stoUD){ 

delete checkID; 

card = cardlterator->Next(); 

continue; 

) 

delete checkID; 

card->GetFunctionResourceUsage(functionDeque); 

fiinctionlterator - functionDeque.CreateSequenceiterator(); 
functionUsage = functjonlterator->Flrst(); 

while (functionUsage != NIL) { 
if (functionNumber ~ 
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functionUsage->GetFunctionNumber()) { 
delete cardlteraton 
delete functionlterator; 
delete slotID; 

5 

TIOFunctionResourceUsage ^saveUsage; 
saveUsage = new TIOFunctionResourceUsage 

(*functionUsage); 
functionDeque. DeleteAIIQ; 
10 return saveUsage; 

} 

functionUsage = functionlterator->Next(): 

} 

delete functionlterator; 
15 card = cardlterator->Next(); 

} 

delete slotID; 

delete cardlteraton 

functlonDeque.DeleteAIIO; 

20 

return NIL; 

} 

Each particular I/O function has a unique identifier 
25 (THardwarelnterfeceldentifier) which is passed as a key to the 

GetFunctionAssignmentO method to obtain the resource assignment from the 
hardware configuration database for the particular I/O function located by the 
FindFunctionBylDO method. The Configuration Recorder for each particular 
expansion card and the conresponding configuration recorder object creates 
30 the unique identifier for each I/O function on the expansion card by 
subclassing from the TIOFunctionHardwarelnterfaceldentifier dass. 

50 



wo 99^9268 



PCT/US99/01740 



It should be noted that the GetFunctionAssignmentO method returns 
the resource assignment for an expansion card even if the expansion card is 
not physically installed in the system as long as the card is registered in the 
hardware configuration database. The GetFunctionAssignmentO method 
throws an exception if the resource assignment is not created, rf there is any 
conflict in creating a resource assignment for a particular I/O function or if the 
I/O function is not registered with the conflict resolver. 

The TIOResourceConflictResolver dass 1 100 includes 
GetResourceConflictsO method which is called only by the card recognizers 
and control panels and retums the conflicts in resource assignment for an I/O 
function. To obtain the resource conflicts for a particular I/O function, a 
unique THardwarelnterfaceldentifierforthe I/O function is passed in as a key 
to the function. The conflicts are retrieved from the resource usage object in 
the hardware configuration databse. The GetResourceConflicts() method 
throws exception if the I/O function is not registered with the resource conflict 
resolver. The code for the method is illustrated below: 

void TIOResourceConflictResolver:GetResourceConflicts (const 
TIOFunctionHardwarelnterfaceldentifier&functionID, 

TCollectionOf <TIOResourceConflict>& conflicts) 
const 

{ 

TIOFunctionResourceUsage ^functionltem; 
TIOFunctionResourceAssignment function; 

If ((functionltem = FindFunctionBylD (functionID)) == NIL) { 
throw (TconflictResohferException 

(TConflictResolverException: ikFunctionNotRegiste 

red)): 

return; 

} 
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if (functionltem->GetAssignment(function) == 

TIOFunctionResourceUsage::kNotAssigned){ 
functbnltem->GetResourceConflicts(conflicts): 

} 

} 

When an I/O function is removed from the system, a 
RemoveFunctionAssignmentO method and a 
RemoveFunctionResourceUsageO method of the 

TIOResourceConflictResolver class 1 100 are called to remove, respectively, 
the resource assignment (TIOFunctionResourceAssignment) assigned to the 
I/O function and the resource usage (TIOFunctionResourceUsage) 
associated with the I/O function. In the case of the 

RemoveFunctionAssignment method(), the caller of the method asserts that 
the resources are not being responded to by the corresponding hardware. 
This method generates an exception rf the resources are In use and also 
generates an exception if the I/O function is not registered with the resource 
conflict resolver. The code for the function is: 



void TIOResourceConflictResolverrRemoveFunctionAssignment (const 

TIOFunctionHardwarelnterfaceidentrfier & 
functionID) const 

{ 

TSequenceOfiterator<TIOCardResourceUsage> *cardlteraton 
TIOCardResourceUsage *card; 
TDequeOf<TIOFunctionResourceUsage> functionDeque; 
TSequenceOflterator<TIOFunctionResourceUsage> *functionlteraton 
TIOFunctionResourceUsage *functionUsage; 
THanJwarelnterfaceldentifier *checklD, 

^cardldentifier; 
TIOFunctk)nHardwarelnterfaceldentifier.:FunctionNumber 
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functionNumber; 

if ((cardldentffier = funclionlD.CopyParent()) == NIL) { 
throw (TconfliclResolverExceptlon 

(TConf|jctResolverException::kFuncllonNotReglstered)); 

} 

cardlterator = fCard.CreateSequencelterator(): 
card = cardlterator->First(); 
functionNumber = functionlD.GetlOFunction(); 
while (card != NIL) { 

checkID = card->CopySlotldentlfier(); 
if {*checklD != *card Identifier) { 
delete checkID; 
card = cardlterator->Next(); 
continue; 

} 

delete checkID; 

card->GetFunctionResourceUsage(functionDeque); 
functionlterator = functlonOeque.CreateSequencelterator(); 
fiinctionUsage = functtonlterator->First(); 

while (fiinctionUsage 1= NIL) { 
if (functionNumber — 

funct}onUsage->GetFunctionNumber()) { 
functionUsage->CtearAssignment(); 
card->SetFunctlonResourceUsage( 

functionDeque); 

delete cardlterator; 
delete functionlterator; 
delete cardldentifien 
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functionDeque.DeleteAIIO; 
return; 



functionUsage = functionlterator->Next(); 

} 

delete functionlterator; 
functionDeque.DeleteAIIO; 
card = cardlterator->Next(); 

} 

delete cardldentifien 

delete cardlterator; 

throw (TconflictResolverException 



(TConflictResolverException::kFunctionNotRegistered)); 



In the case of the RemoveFunctionResourceUsage() method, the 
caller of the method asserts that the resources are not being responded to by 
the conresponding hardware. This method generates an exception if the 
resources are in use or if the I/O function is not registered with the resource 
conflict resoh^er. The code for this function is: 

void TIOResourceConflictResolven:RemoveFunctionResourceUsage(con5t 



TSequenceOflterator<TIOCardResourceUsage> *cardlterator. 



TSequenceOflterator<TIOFunctionResourceUsage> *functionlterator. 



TiOFunctionHardwarelnterfaceldentifier & 



functionID) const 



{ 



TIOCardResourceUsage 
TbequeOf<TIOFunctionResourceUsage> 



*card; 

functionDeque; 



TIOFunctionResourceUsage 



^functionUsage; 
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TIOFunctionHardwarelnterfaceidentifier *functionldentifien 

cardlterator = fCard.CreateSequencelterator(); 
card = cardlterator->First(); 
while (card != NIL) { 

card->GetFunctionResourceUsage(functionDeque); 
functionlterator - fiinctionDeque.CreateSequenceiterator(); 
functionUsage = functionlterator->First(); 
while (functionUsage != NIL) { 
functionldentifier = 

functionUsage->CopyFunctionldentifier(); 
If C'functionldentffier == functionID) { 
functionlterator->Remove(); 
card->SetFunctionResourceUsage(functlonDeque); 
functlonDeque.DeieteAII(); 
delete cardlterator; 
delete fiinctionlteraton 
return; 

} 

delete functionldentifien 
functionUsage = fijnctionlterator->Next(); 

} 

delete functionlterator; 
card = cardlterator->Next(); 

} 

delete cardlterator, 

functionDeque.DeleteAIIO; 

throw (TConflictResolverException 

(TConflictResolverException::kFunctionNotRegistered)); 
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The TIOResourceConflictResolver class 1100 Is associated with a 
dass 1102 named TIOCardResourceUsage and a class 1104 named 
TIOFunctionResourceUsage. The purpose of the TIOCardResourceUsage 
class 1 102 is to encapsulate resource usage infomiation for multiple I/O 
functions on a card. Clients of the resource conflict resolver object retrieve 
the resource usage information for an expansion card from the hardware 
configuration database using the THardwarelnterfaceldentifier for the 
expansion slot in which the expansion card is installed. The 
TIOCardResourceUsage class 1 102 is a monomorphic dass which is 
normally not subclassed by developers. 

The TIOCardResourceUsage dass 1 1 02 includes the typical 
constnjctor and destructor member functions and also includes a plurality of 
unique member functions. For example, a GetFunctionResourceUsage 
member function returns the resource usage of multiple I/O functions on a 
particular expansion the card. This function has the fomi: 

void GetFunctionResourceUsage (TCollectionOf 

<TIOFunctionResourceUsage>& function) const; 

The TIOCardResourceUsage dass 1 102 also indudes a 
SetFunctionResourceUsageO member function. The method implemented by 
this member fonction writes the resource usage of multiple I/O functions on 
an expansion card and has the form: 

void SetFunctionResourceUsage (const TcoilectionOf 

<TIOFunctionResourceUsage>& function); 

The TIOCardResourceUsage class also indudes a 
Thardwarelnterfaceldentifier* CopySlotldentifier() method and a 
SetSlotldentifierO method. The Thardwarelnterfaceldentifier* 
CopySlotldentffier() method returns the THardwarelnterfaceldentifier for the 
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expansbn slot in which the expansion card is installed and the 
SetSlotldentifier() method writes the THardwareinterfaceldentifier for the 
expansion slot in which the expansion card is installed. These functions have 
the following fomi: 

THardwareinterfaceldentifier* CopySlotldentjfier() const; and 
void SetSlotldentifier (const THardwarelnterfaceldentifier& slotlD); 

The purpose of the TIOFunctionResourceUsage class 1 104 is to 
encapsulate resource requirements, such as possible resource assignments 
and resource assignment constraints, and conflict-free resource assignments 
for an individual I/O function. The TIOFunctionResourceUsage class 1 104 
also encapsulates an assignment period, for which the resource assignment 
is valid, and the infomiation about resource conflicts if any resource conflict is 
encountered while producing the conflict-free resource assignment . Clients of 
the resource management system, such as recognizers retrieve an 
lOFunctionResourcellsage object for an I/O function from the hardware 
configuration database using the function number associated with the I/O 
function. The TIOFunctionResourceUsage dass 11 04 is a monomorphic 
class which is nonmally not subclassed by developers. 

The TIOFunctionResourceUsage dass 1 104 indudes the typical 
constructor and destructor memt)er functions as well as a plurality of unique 
member functions. For example the TIOFunctionResourceUsage class 
indudes a SetPossibleAssignmentsQ method and a 
GetPosstbleAssignmentsO method which respectively write and return the 
possible resource assignments for a particular I/O function. They have the 
form: 

void GetPossibleAssignments (TcollectionOf 

<TPossiblelOResourceAssignment>&possibles) const; 
and 

void SetPossibleAssignments (const TcollectionOf 
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<TPossiblelOResourceAssignment>& possibles); 

The TIOFunctionResourceUsage class further includes a 
GetAssignmentConstraintsO method and a SetAssignmentConstraints() 
method which respectively write and retum the constraints in resource 
assignments for a particular I/O function. These functions have the following 
form: 

void GetAssignmentConstraints (TcollectionOf 

<TPossiblelOResourceAssignment>& constraints) const; and 

void SetAssignmentConstraints (const TCollectionOf 

<TPossiblelOResourceAssignment>& constraints); 

A GetAssignmentO method of the TIOFunctionResourceUsage class 
1 104 retums a conflict-free resource assignment for an I/O function while a 
SetAssignment methodQ of dass 11 044 writes the conflict-free resource 
assignment for a particular I/O function into the corresponding 
lOFunctionResourceUsage object. It should be noted, however, that device 
drivers cannot use the GetAssignmentO method to obtain the resource 
assignment for a particular I/O function. Rather, device drivers obtain the 
resource assignment for a particular I/O function via a lOResourceLockEntry 
object as explained below. The GetAssignmentO method retums a first 
enumerated value (kAssigned) if the resource conflict resoh^er object has 
created a resource assignment and a second different value (kNotAssigned) if 
the resource conflict resolver object has not created a resource assignment. 
These function have the following form: 

void EAssignmentStatus GetAssignment (TIOFunctlonResourceAssignment& 

assignment) const; and 
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void SetAssignment (const TIOFunctionResourceAssignment& assignment): 

A GetFunctionNumt)er() method returns the function number 
associated with an i/O function, which number identifies a particular function 
on an expansion board, and a SetFunctionNumber() method writes the 
function number associated with an I/O function. These functions have the 
following fomi: 

TIOFunctionHardwarelnterfaceldentifienrFunctionNumber 

GetFunctionNumber const; and 

void SetFunctionNumber 

(TIOFunctionHardwarelnterfaceldentifier::FunctionNumber functionNumber); 

A GetResourceConflictsO method returns a collection of resource 
conflict objects associated with the resource assignment for an I/O function 
and a SetResourceConflictsQ method writes the resource conflicts associated 
with the resource assignment for an I/O function into the 
lOFunctionResourceUsage object. These functions have the fonm: 

void GetResourceConfiicts (TCollectionOf <TIOResourceConflict>& 

conflicts ) const; and 

void SetResourceConflicts (const TCollectionOf <TIOResourceConflict>& 

conflicts); 

A GetAssignmentPeriodO method returns a resource assignment 
period for a particular resource assignment and returns a first value 
(kThisBoot) if the resource assignment is valid for the current boot period and 
a second different value (kNextBoot) if the resource assignment is valid only 
for the next boot period. A SetAssignmentPeriod() writes the resource 
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assignment period for the assignment into the lOFunctionResourceUsage 
Object. These functions have the foliowing fonn: 

EAssignmentPeriod GetAssignmentPeriod() const; and 

void SetAssignmentPeriod (const EAssignmentPeriod period); 

The TIOResourceConflictResoiver class 1 100 further includes 
ProduceConfllctFreeAssignments method which produces a conflict-free 
resource assignment for the I/O functions on the motherboard and expansion 
cards in the system for a specified boot period. A boot period parameter 
takes on a value which indicates to the conflict resolver object whether the 
conflict resolve object should produce the resource assignment for this boot 
period (kThisBoot) or subsequent boot period (kNextBoot). A 
ProduceConfllctFreeAssignments method of the 
TIOResourceConflictResoiver class 1 100 generates 
lOFunctionResourceAssignment objects for all I/O functions cunrently without 
resource assignments. If there are any conflicts in resource assignnrtents, the 
ProduceConflictFreeAssignmentsO method creates an lOResourceConflict 
object. If any conflict in resource assignments is encountered while 
attempting to generate resource assignments, the 

ProduceConflictFreeAsslgnmentsO method throws an exception, but does not 
change any existing resource assignments. 

Conflfct Free Resource Assignment Methods 

The operation of the ProduceConflictFreeAssignments() method is 
described in detail with reference to flowcharts 12. 13 and 14A, 148. Figure 
12 is a flowchart which shows an illustrative routine for generating a set of 
conflict free resource assignments. The routine starts in the step 1200 and 
proceeds to step 1202 where a collection of all of the functions on the 
expansion cards in the system is created from the lOCardResourceUsage 
objects which have been registered with the conflict resolver object as 
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previously described. In this step, the routine iterates through the 
lOCardResourceUsage objects and extracts all lOFunctionResourceUsage 
objects and places them into an an^y. 

Next, in step 1204, limit counts are set for memory assignments, I/O 
5 register assignments, DMA Channel assignments and intenrupt socket 
assignments. These limit counts are obtained from the appropriate memory, 
register, DMA and interrupt constraint objects which are nested in the 
PossiblelOResourceAssignment objects. These limits are used during the 
next step (1206) to determine when all resource combinations have been 

10 tried so that the conflict resolver can decide when a conflict resource 
allocation cannot be made. 

Next in step 1206, the function collection created in step 1202 is 
examined and possible resource allocations are built using the 
PossiblelOResourceAssignment objects and their nested 

15 lOMemoryConstraint, lORegisterConstraint, DMAConstraint and 

InterruptConstraint objects. The set of possible assignments is then checked 
by looping through each function using the lOFunctionResourceUsage 
objects to determine whether that assignment conflicts with any other 
assignments. If a conflict is found, as indicated in step 1208, then a check Is 

20 made to determine whether additional resource combinations reamin to be 
tried as set forth in step 1210. Ifthere are additional resource combinations • 
that have not been tried, the routine returns to step 1206 where new possible 
resource assignments are constructed and tried. 

if, in step 1210, there are no further untried resource combinations, 

25 then the routine proceeds to step 1214 and creates a conflict object and 
throws an exception indicating that a conflict free resource allocation cannot 
be achieved. In a preferred routine, the conflict object is generated ttie first 
time a conflict is detected. However, even though a conflict has been 
detected, the routine continues to try additional resource combinations until all 

30 resource combinations have been tiled. If a conflict free resource allocation 
cannot be obtained, than the originally-created conflict object is retumed to 
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the user so that the user can determine why the conflict occun^ed and how to 
remove it. The routine then finishes In step 1216. 

Alternatively, if in step 1208, no conflict is found with a particular 
resource allocation, then the routine proceeds to step 1212 where the 
5 lOResourceCardUsage objects are updated using the new resource 
albcations. The routine then finishes in step 1216. 

Figure 13 is an illustrative flowchart indicating a routine for creating a 
function collection anray from ttie TIOCardResourceUsage objects as set forth 
in step 1202. In particular, in step 1302, two an^ys are created to hold the 
10 function collections. These are designated as t>oot and non-t>oot arrays. The 
boot array holds the functions which are essential for the current boot 
operation whereas the non-boot array holds functions that are not essential 
for tiie current boot operation (for example, functions that are used on a 
subsequent boot.) 

15 At step 1 304. the routine loops through a deque containing the 

TIOCardResourceUsage objects and inserts pointers to essential functions 
into the boot anray. Next in step 1306, the routine loops through the 
lOCardResourceUsage objects and inserts function pointers to the non- 
essential functions into the non boot an^y. In step 1308, the boot and non 

20 boot anrays are urged to torm a sorted function collection. 

Next, in step 1310, the possible lOResourceAssignment objects for 
each of the functions are retrieved to build a deque of possible resource 
assignments for each function. The routine then finishes in step 1312. A 
code fragment which Illustrates an actual routine for performing this routine is 

25 as follows: 

void TIOResourceConfllclResoh^en:CreateFunctionCollectionFromCards() 
{ 

TDequeOf<TIOFunctionResourceUsage> functionDeque; 
30 TIOFunctionResourceUsage ^function; 

TSequenceOflterator<TIOFunctionResourceUsage> *functionlterator, 
TIOCardResourceUsage *card: 
TSequenceOflterator<TIOCardResourceUsage> *cardlteraton 
int index, bootlndex = 0, nonBootlndex = 0, indexCollection = 0; 
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TArrayOf<TIOFunctionResourceUsage> functionForBobt, 

functionNonBoot; 

ConflictResolverFunctionlndex *whlchCollectjon; 
TArrayOf<struct ConflictResolverFunctionlndex> bootlndexes, 

nonBootlndexes; 

candlterator = fCard.CreateSequencelterator(); 

functionForBoot.SetAutoGrowFlag(TRUE); 

functionNonBoot.SetAutoGrowFlag(TRUE): 

bootlndexes.SetAutoGrowFlag(TRUE); 

nonBootlndexes.SetAutoGrowFlag(TRUE); 

for (card = cardlterator->First(); card != NIL; card = 

cardlterator->Next()) { 
card->GetFunctionResourceUsage(functionDeque); 

functionlterator = fijnctionDeque.CreateSequencelterator(); 
for (function = functionlterator->First(); function != NIL; 

function = functionlterator->Next()) { 

whichCollection = new struct 

ConflictResolverFunctionlndex; 
whichColiection->indexPriority = 

function->GetFunctionPriority(); 
whichCollection->indexlntoCollection = 

indexCollection'4-->'; 

If (functfon->GetFunctionPriority() = 

TIOFunctionResourceUsage::kEssentialForBoot){ 
functionForBoot7^tPut(txx)tlndex, function): 
bootlndexes.AtPut(bootlndex, whichCollection); 
bootlndex++; 

}eise{ 

functionNonBootAtPut(nonBootlndex, function); 
nonBootlndexes^tPut(nonBootlndex, 

whichCollection); 

nonBootlndex++; 

} 

} 

delete functionlterator; 
functionDeque.RemoveAIIO: 

} 

fFunctionCount = bootlndex + nonBootlndex; 

fFunctions = new FunctionPossibleAssignment[fFunctionCount]; 
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// Merge Boot and Non-Boot function collection into one as a sorted 

// collection 

// 

indexCollection = 0; 

for (index = 0; index < bootlndex; index++) { 

BuildFunctionPossible(fFunctions[indexCollectionl, 

*fLinctionForBoot.At(index), *bootlndexes.At(index)); 
indexCollection-f-f; 

} 

for (index = 0; index < nonBootlndex; index++) { 

BuildFunctionPossible(fFunctions[indexCollection]. 
*functionNonBoot.At(index), ^nonBootlndexes.At(index)); 
indexCollection++; 

} 

functionForBoot. DeleteAII(); 

functionNonBoot.DeleteAII(); 

bootlndexes.DeleteAIIO; 

nonBootlndexes.DeleteAIIO; 

delete cardlteraton 

return; 



void TIOResourceConfiictResoiver:BuildFunctionPossibie( 

TIOResourceConflictResoiverDoerrrFunctionPossibieAssignment & 
function, 

TIOFunctionResourceUsage & functionUsage, 
ConfiictResoiverFunctionlndex & index) 

( 

TIOFunctionResourceAssignment assignment; 
TSequenceOflterator<TPossiblelOResourceAssignment> *iteraton 
TDequeOf<TPossiblelOResourceAssignment> possibleDeque; 
TPossibleiOResourceAssignment ^possible; 
int maxRegisterCount = 0, maxMemoryCount = 0, 

maxInterruptCount = 0, 
maxDMACount = 0; 
functionUsage.GetAssignmentConstraints(possibleDeque); 
if (possibleDeque.CountO == 0) 

functionUsage.GetPossibleAssignments(possibleDeque); 
function.fPossibieCount = possibleDeque.CountO; 
iterator = possibieDeque.CreateSequencelterator(); 
function.fPossibles = new 

PossibleResources[function.fPossibleCount]; 

possible iterator->FiR5t(); 
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for (int i = 0; I < ftjnction.fPossibleCount; possible = 

iterator->Next()) { 
CreateMemoryPossible(function.fPossibles[i], ^possible, 

maxMemoryCount); 
5 CreateRegisterPossibie(function.fPossibles[Q, ^possible, 

maxRegisterCount); 
CreateDMAPossible(function.fPossibles[Q. ""possible, 

maxDMACount); 
CreatelntemjptPossible(function.fPossibles[i], ^possible, 
10 maxIntenruptCount); 
} 

if (maxMemoryCount) { 

function.fMemoryBaseAddresses = new 
15 TPossibielOResourceAssignment::TIOMemoryConstraint:: 

BaseAddress[maxMemoryCount]; 
function.fMemoryUseBooiean = 

new Boolean[maxMemoryCount]; 

} else { 

20 function.fMemoryBaseAddresses = NIL; 

function.fMemoryUseBooiean = NIL; 

} 

if (maxRegisterCount) 
25 fiinclion.fRegisterBaseAddresses = 

newTPossiblelOResour€eAssignment::TIORegisterConstraint:: 
BaseAddress[maxRegisterCount]; 

else 

function.fRegisterBaseAddresses = NIL; 

30 

If (maxDMACount) 

function.fDMAChannelNumbers = new 

TDMAChannellnfomnation::DMAChannelNumber 
[maxDMACount]; 

35 else 

function.fDMAChannelNumbers = NIL; 

if (maxInterruptCount) 

function.flntenruptSocketNumbers = new 
40 lntenruptSocketNumber[maxlntenruptCount]; 
else function.flntenruptSocketNumbers = NIL; 
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delete iterator, 
possibleDeque.DeleteAII(); 

function.fConflicts - NIL; 
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function.fConstructedAsslgnment = NIL; 
function.fHaveAssignment = FALSE; 
function.fMemoryCount = 0; 
function.fRegisterCount = 0; 
function.flntenuptCount = 0; 
fiinction.fDMACount = 0; 

funclion.fPunctionlndex = index.indexIntoCollection; 
function.fPunctionldentifier = functionUsage.CopyFunctionldentifier(); 
// 

// A constructed assignment is not created if the Resolve Period is 

//for the Next Boot, OR if there is no existing assignment 

// 

if (fResolvePeriod == TIOFunctionResourceUsage::kNextBoot || 
functjonUsage.GetAssignment(dssignment) == 
TIOFunctionResourceUsage::kNotAssigned){ 

// 

// Construct Assignments 

// 

if (maxIntenuptCount) 

function.flnterruptAssignments = 

new lnterruptAssignment[maxlntenruptCount]; 
else function.flnterruptAssignments = NIL; 

if (maxDMACpunt) 

functk>n.fDMAAssignments = new 

DMAAssignment[maxDMACount]; 
else function.fDMAAssignments = NIL; 

if (maxMemoryCount) 

function.fMemoryAssignments = new 

MemoryAssignment[maxMemoryCount]; 
else function.fMemoryAssignments = NIL; 

if (maxRegisterCouht) 

function.fRegisterAssignments = new 

RegisterAsstgnment[maxRegisterCount]; 
else functk>n.fRegisterAssignments = NIL; 

retum; 

} 



function.fHaveAssignment = TRUE; 

TDequeOf<TIOFunctionResourceAssignment::TIOMemoryAssignment 

memoryDeque; 
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TIOFundionResourceAssignmentiTIOMemoryAssignment 

*mernory; 

TDequeOf<TIOFunctionResourceAssignment:TIORegisterAssignm^ 

registerDeque; 

TIOFunctionResourceAssignment::TIOReglsterAssignment *io: 

TDequeOf<TIOFunctionResourceAssignment::TDMAAssignment> 

dmaDeque; 

TIOFunctionResourceAssignment::TDMAAssignment *dma; 

TDequeOf<TIOFunctionResourceAssignment::TlntermptAssignment> 

interaiptDeque; 

TIOFunctionResourceAssignment::TlnternjptAssignment ^interrupt; 

assignment.GetMemoryAssignment(memoryDeque); 
if (memoryDeque.CountO) { 

TDequeOflterator<TiOFunctionResourceAssignment:: 
TIOMemoryAssignment> memorylterator(&memoryDeque); 

MemoryAssignment *memoryAssignment; 
function.fMemoryCount = memoryDeque.CountO; 
fiincUon.fMemoryAssignments = 
memoryAssignment = 

newMemoryAssignment[function.fMemoryCount]; 

for (memory = memorylterator.First(); memory; memory = 

memorylterator.NextO, merTK)ryAssignmenH+) { 
memoryAssignment->fCanShare = 

memory->lsSharable(); 
memoryAssignment*>fBaseAddress = 

memory->GetBaseAddress(); 
memoiyAssignment->fLength = memory->GetLength(): 

} 

} 

assignmeritGetlOAssignment(registerDeque); 
if (registerOeque.CountO) { 

TDequeOflterator<TIOFuncBonResourceAssignment:: 
TIORegisterAssignment>registerlterator(&registerDeque); 
RegisterAssignment *registerAssignment; 
funcUon.fRegisterCount = registerDeque.CountQ; 
function.fRegisterAssignments = registerAssignment = 
new RegisterAssignment[registerDeque.Count()]; 

for (10 = registerlterator-FirstO; lo; io= registerlterator.Next(). 
registerAssignment++) { 
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registerAsslgnment->fCanShare = io->lsSharable(): 
regjsterAssignment->fBaseAddress = 

io->GetBaseAddress(); 
registerAssignment->fLength = io->GetLength(); 

} 

assignment.GetDMAAssignment(dmaDeque); 

if ((functlon.fDMACount = dmaDeque.Count()) != 0) { 

TDequeOflterator<TIOFunctionResourceAssignment:: 
TDMAAssignnnent> dmaiterator(&dmaDeque): 
DMAAssignment *dmaAssignment: 

function.fDMAAssignments = dmaAssignment = 

new DMAAssignment[function.fDMACount]; 
for (dma = dmalterator.First(); dma; dma = dmalterator.Next(). 

dmaAssjgnment++) { 
dmaAssignment->fCanShare = dma->isSharable(); 
dmaAssignment->fDMAChannel = 

dma->GetChannelNumbeF(); 

} 

} 

assignmenLGetlntemjptAss^nment(interruptDeque): 

If ((funclion.flntemjptCount = lntemjptDeque.Ck)unt()) != 0) { 
TDequeOflteratoKTlOFunctionResourceAssignment:: 
TlntemjptAssignment> intemjptlterator(&intemiptDeque): 
IntemiptAssignment'interruptAssignment; 
fiinctk>n.flnterruptAssignments = intenruptAssignment 

= new lntenruptAssignment[function.finterruptCount]; 
for (interrupt = intenuptlterator.FirstO; interrupt; interrupt = 
interruptlterator.Next(), 

intennuptAssignment+>) { 

interruptAss^nment->fCanShare = 

interrupt->lsSharable(); 
intemjptAssignment->finterruptSocket = 

intenupt>>GetlnterruptSocket(); 

) 

} 

} 

void TIOResourceConflictResolver::CreateMemoryPossible( 

TIOResourceConflictResolverDoenzPossibleResources & function, 
TPossiblelOResourceAssignment & possible. 
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int & maxCount) 

TDequeOf<TDequeOf<TPossiblelOResourceAsslgnment:: 
TIOMemoryConstraint> > masterDeque; 
TDequeOf<TPossiblelOResourceAssignment::TIOMemoryConstraint> 

^memoryDeque; 
TSequenceOflteratoKTPosslblelOResourceAssignment:: 
710MemoryConstraint> ^iterator 
TSequenceOflterator<TDequeC)f<TPossiblelOResourceAssignment:: 
TIOMemoryConstraint> > *collectionlterator; 

TPossiblelOResourceAssignment::TIOMemoryConstraint *memoiy; 
MemoryPossible ^memoryResource; 
MemoryCollection *memoryCollection; 

possible.GetMemoryConstraints(masterDeque): 

if ((function.fMemoryCollectJonCount = masterDeque.Count()) == 0) { 

function.fMemoryPossible = NIL; 

return; 

} 

memoryCollection = function.fMemoryPossible = 

newMemoryCollection[funcUon.fMemoryCollectionCount]; 
collectionlterator = masterDeque.CreateSequencelterator(); 
for (memoryDeque = collectioniterator->First(); memoryDeque; 

menioryDeque = collectionlterator->Next(), 
memoryColiection-»"i-) { 
iterator = memorypeque->CreateSequencelterator(); 
memoryCollection->fMemoryCount = memoryDeque->Count(): 
iff (menioryCollection->fMemoryCount > maxCount) 
maxCount = memoryCollection->fMemoryCount; 

memoryResource = memoryCollection->fMemoryPossible = 
new MemoryPosslble[memoryCollection->fMemoryCount]; 
for (memory = iterator->First(); memory; 

memory = iterator->Next(), 
memoryResource++) { 
memoryResource->fLowerBaseAddress = 

memory->GetLowerBaseAddress(); 
memoryResource->fUpperBaseAddress = 

memory->GetUpperBaseAddress(); 
memoryResource->fLength = memory->GetLength(); 
menrK>ryResource->flncrement = 

memory->GetBaselncrement(); 
memoryResource->fConstraint = 

memory->GetConstraintNumber(); 
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memoryResource->fCanShare = 

memory->lsSharable(): 

memory->GetMemoryUsageMode( 

memoryResource->fMemoryMode); 

} 

delete iterator; 

} 

delete coilectionlterator. 
::DeepDelete(masterDeque); 

} 

voldTIOResourceConfllctResolven:CreateRegisterPossible( 
TIOResourceConfllctResolverDoen:PossibleResources& 
function. TPossiblelOResourceAssignment& 
possible, int& maxCount) 

{ 

TDequeOf<TDequeOf<TPossiblelOResoutceAssignment: 

TIORegistBrConstraint> > masterOeque; 
TDequeOf<TPossibleiOResourceAssignment: 

TIORegisterConstraint> *registerDeque; 
TSequenceOf)terator<T0equeOf<TPosslblelOResourceAssignment:: 

TIORegisterConstraint> > 'coilectionlterator, 
TSequenceOflteratorcTPossiblelOResourceAssignment:: 

TIORegistefConstraint> 'iteraton 
TPossiblelOResourceAssignment:T10RegisterConstraint*io; 
RegisterPossible *registerResource; 
RegisterCollection *registerCollection; 

possible.GetlOCortstraints(masterOeque): 

If ((functlon.fReglsterCollectionCount = masterDeque.Count()) = 0) { 
function.fRegisterPossible ~ NIL; 
return; 

} 

coilectionlterator = masterOeque.CreateSequencelterator(); 
registerCollection = function.fRegisterPossible = 

new RegisterCollection[functbn.fRegisterCollectionCount]; 

for (registerOeque = collectionlterator->First(); registerOeque; 

registerOeque - collectionlterator->Next(). 

registerCollection-t-t-) { 
registerCollection->fRegisterCount = registerDeque->Count(); 
registerResouFce = registerCollection->fRegisterPossible = 
newRegisterPossibie[registerCollection->fRegisterCount]; 

If (registerCollection->fRegisterCount > maxCount) 
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maxCount = registerCollection->fRegisterCount: 
iterator = registerDeque->CreateSequencelterator(); 
for (fo = iterator->First(); lo; io = jterator->Next(), 

regtsterResource-i--i*) { 
registerResource->fLowerBaseAddress = 
io->GetLowerBaseAddress(); 
registerResource->fUpperBaseAddress = 
io->GetUpper6aseAddress(); 
reglsterResource->fl.ength = io->GetLength(); 
registerResource->fincrement = io->GetBaselncrement(): 
registerResource->fConstraint = 

io->GetConstraintNumber(); 
rBgisterResource->fCanShaire = io->lsSharable(): 
io->GetRegisterUsageMode( 

registerResouFce->fRegisterMode); 

} 

delete iterator. 

} 

delete collectionlterator; 
::DeepOelete(masterOeque); 

} 

void TIOResourceGonflictResolverDoen:CreateDMAPossible( 

TIOResourceConflictResoiverDoeniPossibleResources & funcA^^ 
TPossiblelOResourceAss^nment & possible, 

int& maxCount) 

{ 

TDequeOf<TDequeOf<TPossiblelOResourceAssignment:: 

TDMAConstralnt> > masterDeque; 
T[)equeOf<TPossiblelOResourceAsstgnment::TDMAConstraint> 

*dmaDeque; 

TSequenceOflterator<TDequeOf<TPosslblelOResourceAssignment:: 

TDMAConstraint> >*collectionlterator; 

TSequenceOflterator<TPossiblelOResourceAssignment:: 

TDMAConstraint> *iterator, 

TPosslbielOResourceAsslgnment::TDMAConstraint *dma; 

DMAPossible *dmaResource; 

DMACollection *dmaCollection: 

possible.GetDMAConstraints(masterOeque); 

If ((function.fDMACollectlonCount = masterDeque.Count()) == 0) { 

function.fDMAPossible = NIL; 

return; 

} 

dmaCollectbn = function.fDMAPossible = 
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new DMA(^lleGtion[fiinction.fDMACollectionCount]; 
collectionlterator = masterDeque.CreateSequencelterator<); 
for (dmaOeque = collectionlterator->First(); dmaDeque; dmaDeque = 
collec4ionlterator->Next(), dmaCollecBon-i-+) { 
dmaCollection->fDMACount = dmaDeque->Count(); 
dmaResource = dmaCollection->fDMAPossible = 

new DMAPossible[dmaColiection->fDMACount]; 
if (dmaCollection->fDMACount > maxCount) 

maxCount = dmaCollection->fDMACount; 
iterator = dmaDeque->CreateSequencelterator(); 
for (dma = iterator->Flrst(); dma; dma = iterator->Next(), 

dmaResource-*-+) { 
dmaResource->fLowerDMAChannel = 

dma->GetLowerChannelNumber(); 
dmaResource->fUpperDMAChannel = 

dma->GetUpperChannelNumber(); 
dmaResource*>fConstraint = 

dma->GetConstraintNumber(); 
dmaResource->fCanShare = dma->lsSharabie(); 
dma->GetDMAUsageMode(dmaResource->fDMAMode); 

} 

delete iterator; 

} 

::DeepDelete(masterDeque); 
delete collecttonlteraton 



void TIOResourceConfllctResolverDoer.:CreatelnterruptPosstble( 

TIOResourceConflictResolverDoen:PossibleResources & function, 
TPossiblelOResourceAssignnient & possible, int& maxCount) 

{ 

TDequeOf<TDequeOf<TPossiblelOResourceAssignnient: 

TlntemjptConstraint> > masterDeque; 
TDequeOf<TPossiblelOResourceAssignment:: 

TinteniiptConstraint>^interruptOeque; 
TSequenceOflterator<TDequeOf<TPossiblelOResourceAsslgnment:: 

TlnterruptConstraint> > ^coliectionlteraton 
TSequenceOflterator<TPossiblelOResourceAssignment:: 

TlnterTuptConstraint> *lterator, 
TPossiblelOResourceAssignmentiTintemjptConstraint *intenrupt; 
IntermptPosslble *intermptResource; 
IntermptCollection ^interruptCollection; 

possible.GetlntenruptConstraints(masterDeque); 

if ((function.flnterruptCollectionCount = masterDeque.Count()) == 0) { 
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function.flntermptPosslble = NIL; 
return; 

} 

function.flntermptPosslble = intenruptCollection = 

new lntermptCollection[function.flntemjptCollectionCount]; 
collectionlterator = masterDeque,CreateSequencelterator(); 
for (IntenruptDeque = collectionlterator->Flrst(); intermptDeque; 
intenxiptDeque = collectionlterator->Next(), 

intenuptCollection++) { 
lntenruptCollection->flntenruptCount = intenruptDeque->Count(); 
If (intenruptCollection->flnterruptCount > maxCount) 

maxCount = intemiptCollectlon->flntenruptCount; 
IntenuptResource = 
intenruptColiection->flntemiptPossibie = 
new lntenruptPossibleIintemjptCollection-> 

flntenruptCountJ; 
iterator = internjptDeque->CreateSequencelterator(); 
for (intenupt = iterator->Flrst(); intenrupt Intenrupt = 
iterator->Next(), interruptResource++) { 
interruptResource->fLowerlnterruptSocket = 
intemjpt->GetLowerlnterajptSocket(); 
intenruptResource->fUpperlnterruptSocket = 
intenrupt->GetUpperlntenuptSocket(); 
intemjptResource->fConstraint = 

interrupt->GetConstraintNumber(); 
lnterruptResource->fCanShare = lnteniipt->lsSharable(); 
interTupt->GetlnterruptUsageMode( 

interruptResource->flnteniiptMode); 

} 

delete iterator. 



delete collectionlterator; 
::DeepDelete(masterDeque); 

} 

Figures 14A and 14B, when placed together, fonn a flowchart that 
illustrates a routine which k)ops through the funcHons and checks for conflicts 
as set forth in step 1206. This routine starts in step 1400 and proceeds to 
step 1402, where is determined whether any additional functions remain for 
which resources must be assigned. If not, the routine proceeds, via off-page 
connectors 1419 and 1421, to finish in step 1434. If more functions remain, 
the routine proceeds to step 1406 where a new function is obtained from the 
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function collection assembled by the routine shown in Figure 13. The function 
is checked to see whether resources have already been assigned. If they 
have, the routine proceeds back to step 1402 to check for additional 
functions. If not, the routine proceeds to step 1410 where a new combination 
5 of memory, DMA, I/O Register and Interrupt resources is created. 

Next, the routine proceeds to step 1412, where it loops through 
assignment variables to generate new possible resource assignments. The 
routine then proceeds via off-page connectors 1418 and 1422 to step 1424 
where, for each assignment variable, each function is looped through to 
10 check for conflicts. In step 1426, the routine checks for conflicts in the 
Intenrupt, DMA, I/O register and memory assignments for the cunrent 
functions. 

If a conflict is not detected in step 1428, then the routine finishes in 
step 1434. Altemativeiy, if a conflict is detected, the routine proceeds to step 

15 1430 where a conflict object is generated on the first "pass through the loop" 
as described prevk)usly. Next, in step 1432, a check is made to determine 
whether there are any additional resources that can be assigned. If so, the > 
routine proceeds via off-page connectors 1420 and 1416 back to step 1410 
where a new combination of resources is created and the process is 

20 repeated. 

Alternatively, if in step 1432, there are no more resources to t>e 
assigned, the routine finishes in step 1434. As previously mentioned^ if a 
conflict object has been generated, an exception will be thrown to alert the 
user of the conflict situation. An illustrative code fragment which performs the 
25 steps shown in Figures 14A and 14B is as follows: 



Boolean TIOResourceConflictResolvenrLoopThroughFunction ( 
int currentlndex) 

{ 

30 FunctionPossibleAssignment *thisFunction; 

if (curenUndex >= fPunctionCount) 
return FALSE; 
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thisFunction = &fFunctions[currentindex1; 
// 

// If the function already has an assignment, then skip it. 

// 

5 if (thisFunction->fHaveAssignment == TRUE) { 

cun-entlndex-M-; 

If (currentlndex < fPunctionCount) 

return LoopThroughFunction(cunBntlndex); 

else 

10 return FALSE; 

} else { 

PossibleResources *thisPossible; 
int possiblelndex; 
thisPossible = thisFunction->fPossibles; 
15 for (possiblelndex = 0; possiblelndex < 

thisFunction->fPossibleCount; 
possiblelndex++, thisPossible++) { 
if (LoopThroughPossibleResources(MhisPossible, 
*thisFunction, currentlndex)) { 
20 fFirstPass = FALSE; 

} else { 

return FALSE; 

} 

} 

25 return TRUE; 



30 Boolean TIOResourceConfllctResolven:LoopThroughPossibleResources( 
TIOResourceConflictResolverrPossibleResources & thisPossible, 
TIOResourceConflictResolverrFunctionPossibleAsstgnment & 
thisFunction, int currentlndex) 

{ 

35 MemoryCollection *memoryltem; 

RegisterColleclion *registerltem; 
InterruptCollection *intenruptltem; 
DMACollection ^dmaltem; 
Int menrarylndex, registerlndex, intemjptlndex, dmalndex; 
40 Boolean intenruptLooppedOnce, dmaLooppedOnce, 

registerLooppedOnce, 
memoryLooppedOnce; 

// 

// The program has make at least one iteration at each resource, 
45 // even if the thisPossible does not use a 

// particular hardware resource. If a resource is not to be used, 
// then if s skipped - But the other resources (used or not) 



75 



wo 99/39268 



PCT/US99/01740 



// are looped through. 

// 

interruptitem = thisPossible.flnterruptPossible; 
interaiptLooppedOnce = FALSE; 
interruptlndex = 0; 

while(tnterruptlndex < thisPossible.flnteiruptCollectionCount |i 

intermptLooppedOnce == FALSE) { 
intemiptLooppedOnce = TRUE; 
interTuptlndex++; 

dmaltem = thlsPossible.fDMAPossible; 
dmaLooppedOnce = FALSE; 
dmalndex = 0; 

while (dmalndex < thisPossible.fDMACollectionCount || 
dmaLooppedOnoB == FALSE) { 
dmaLooppedOnce = TRUE; 
dmalndex+'f; 

reglsterltem = thisPossibie.fRegisterPossible; 
registerLooppedOnce = FALSE; 
registerindex = 0; 
while (registerindex < 

thisPossible.fRegisterCollectionCount II 

registerLooppedOnce == FALSE) { 
registerindex-M-; 

registerLooppedOnce = TRUE; 
memoryltem = thisPossible.fMemoryPossible; 
menraryLooppedOnce = FALSE; 
memoryindex = 0; 
while (memoryindex < 

thisPossible.fMemoryCollectionCount 
II memoryLooppedOnce == FALSE) { 
memoryLooppedOnce = TRUE; 
memorylndex++; 

if (LoopThroughAssignmentVariables( 
thisPossible, thisFunction, 
currentlndex, interruptitem. 
dmaltem, registerltem, 
memoryltem) == FALSE) { 

ConstructNewAssignment(thisFunction, 

interruptitem, dmaltem, reglsterltem, 

memoryltem); 

return FALSE; 

} 

fFirstPass = FALSE; 
if (memoryltem) 

memoryltem++; 
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if (registeritem) 

registerltem++; 

} 

if (dmaitem) 

dmaltem++; 

} 

if (interruptitem) 

interruptltem-i-+; 

} 

thisFunction.fHaveAssignment = FALSE; 
retumTRUE; 



Boolean 

TIOResourceConflictResolverDoerrLoopThroughAssignmentVariables ( 

TIOResourceConf|jctResofverDoer:PossibleResources & thisPossible, 
TIOResourceConflictResolverDoer:FunctionPossibleAssignment& 
thisFunction, int cunrentlndex, 

TIOResourceConflictResolverDoerrlnterruptCollectJon *interruptltem, 
TIOResourceConflictResolverDoer:DMACoilection ^dmaitem, 
TIOResourceConflictResolverDoer::RegisterCollection *registerltem, 
TIOResourceConflictResolverDoeniMemoryCollection *memoryltem) 

{ 

InterruptSocketNumber *intemjptCurrent; 
TDMAChannelln1bnnation::DMAChannelNumber ^dmaCurrent; 
TPossiblelOResourceAssignment::TIORegisterConstramt:: 

BaseAddress *loweriOAddress; 
TPossiblelOResourceAsslgnment::TIOMemoryConstraint:: 

BaseAddress ^lowerMemAddress; 
Boolean ^useMemoryltem; 
IntenruptAssignment ^intemiptAssignment; 
MemoryAsstgnment ^memoryAssignment; 
RegisterAssignment *registerAssignment; 
DMAAssignment ^dmaAssignment; 
Int i; 

//RemoveConstructedAssignments(thisFunction); 
thisFunctk>n.fMemoryCount = 0; 
thisFunction.fRegisterCount = 0; 
thisFunction.fDMACount = 0; 
thisFunction.flnterruptCount = 0; 
thisFunction.fHaveAssignment = TRUE; 
// 

// Loop Through Each of the Variables Assignments 
// 

if (interruptitem) { 

InterruptAssignment = thisFunction.flnterruptAssignments; 
thisFunction.flntemjptCount = interruptltem->flnterruptCount; 
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interruptCunrent = thisFunction.flnterruptSocketNumbers; 

for (i = 0; i < thisFunction.flnteraiptCount; i++) { 
inteniiptAssignment->fCanShare = 
interruptltem->flnterruptPossible[0.fCanShare; 
intemjptCurrent[il = 

intermptltenv>flntermptPossible[n.fLowerlntemjptSocket; 

} 

} 

if (dmaltem) { 

dmaAssignment = thIsFunction.fDMAAsslgnments; 
thisFunction.fDMACount = dmaltem->fDMACount; 
dmaCurrent = thisFunction.fDMAChannelNumbers; 
for (i = 0; i < dmalteni->fDMACount; i++) { 
dmaCunrent[q - 

dmaltem->fDMAPossible[il.fLowerDMAChannel: 
dmaAssignmentH.fCanShare = 

dmalteni->fDMAPossible[il.fCanShare; 

} 

If (registerltem) { 

registerAssignment = thisFunction.fRegisterAssignments; 
thisFunction.fRegisterCount = registerltem->fRegisterCount; 
lowerlOAddress = thisFunction.fRegisterBaseAddresses; 
for (i = 0; i < registerltem->fRegisterCount; { 
reglsterAssignmentpl.fCanShare = 

registerltem->fRegisterPossible[i].fCanShare; 
regjsterAssignment[i].fLength = 

registerlterTV>fRegisterPGSsible[0.fLength; 
iowerlOAddress[i] = 

registerltem->fRegisterPossible[0.fLowerBaseAddress; 

} 

} 

If (memoryltem) { 

memoryAsstgnment = thisFunction.fMemoryAssignments; 
thisFunction.fMemoryCount = merTK)ryltem->fMemoryCount; 
useMemoryttem = thisFunctton.fMemoryUseBoolean; 
lowerMemAddress = thisFunction.fMemoryBaseAddresses; 

for (i = 0; i < memoryltem->fMemoryCount; i++) { 

If (memoryltenfv>fMemoryPossiblep].fMemoryMode. 
GetMemoryTypeO ~ 
TIOMemoryReference::kCardMemory) { 
useMemoryltemp] = TRUE; 
memoryAssignment[Q.fCanShare = 

memoryitem->fMemoryPossible[q.fCanShare; 
memoryAssignment[i].fLength = 



78 



wo 99/39268 



PCTAJS99/01740 



memorylterTV>fMemoryPossible[i].fLength; 
lowerMemAddress[i] = 
memoryltem-> 

fMemoryPossible[i].fLowerBaseAddress; 

memoryAsslgnmentH.flsCardMemory = TRUE; 
} else { 

useMemoryltemp] = FALSE; 
memoryAssignmentp].flsCardMemory = FALSE; 

) 

} 

} 

for (Boolean processlnterrupt = TRUE; processlntermpt;) { 
if (interoiptltem) { 

for (i = 0; I < interruptltem->flntenruptCount; { 
interruptAssignment[i].flnterruptSocket = 
inteiTuptCurrent[i]; 

} 

} 

if (dmaltem){ 

for (i = 0; I < dmaltem->fDMACount; i++) 
dmaCunrentp] = 

dnialtem->fDMAPossible[0.fLowerDMAChannel; 

} 

for (Boolean processDMA = TRUE; processDMA;) { 
if(dmaltem){ 

for (I = 0; i < dnialtem->fDMACount; { 
dmaAssignmentpl.fDMAChannel = 
dmaCun^ent[i]; 

} 

} 

if (registerltem){ 

for (i = 0; I < registerltem->fRegisterCount; 
lowerlOAddress[0 = registeritem-> 
fRegisterPossible[i].fLowerBaseAddress; 

} 

for (Boolean processRegister = TRUE; processRegisten) 

If (registerltem) { 

for (j = 0; i < registerltem->fRegisterCount: 

[++){ 

registerAssignment[q.fBaseAddress = 
lowerlOAddressO]; 

} 

} 
// 
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// Only look at memory If there is item, AND the 
// item represents actual card memory (as 
// opposed to a card with no on-board memory that 
// uses Host Memory for I/O) 

// 

If (memoryltem) { 

for (i = 0; i < memoryltem->fMemoryCount; 

i++) 

if (useMemoryltem[i]) lowerMemAddress[i] - 

memoryltem->fMemoryPbssible[i]. 

fLowerBaseAddress; 

} 

for (Boolean processMemory = TRUE; 

processMemory:) { 
if (memoryltem) { 
for (i = 0; i < 

memoryltem->fMenrK)ryCount; 
i++) 

if (useMemoryltem[i]) { 
memoryAssignment[Q. 
fBaseAddress = 
iowerMemAddress[i]: 
} 

} 

if (lsAssignmentWithinPlatfomiUmits( 

thisFunction)) { 
If (CheckAssignrnentForConflict( 
thisFunction, 
cunBntlndex) == FALSE) { 
return FALSE; 

} 

} 

fFirstPass = FALSE; 
if (memoryltem == NIL) 
breaic; 

for (i = 0; I < memoryltem->fMemoryCount; 

!++){ 

lowerMemAddressQ += 
memoryltem-> 

fMemoryPossibie[i].fincrement; 
if (useMemoryltem[i]) { 

if (lowerMemAddress[Q > 
memoryltem->fMemoryPossibie[Q. 

fUpperSaseAddress) { 
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processMemory = 
FALSE; 

break; 
}else processMemory = 
TRUE; 

} 

} 

} 

If (registerltem == NIL) 
break; 

for (i = 0; i < regjsterltem->fRegisterCount; { 
lowerlOAddressp] += 
registerltem-> 

fRegisterPossible[Q.flncrement; 
If (lowerlOAddress[Q > 
registerltem->fRegisterPossible[i]. 

fUpperBaseAddress) { 
processRegister = FALSE; 
break; 

} else processRegister = TRUE; 

} 

} 

if(dmaltem~NIL) 
break; 

for (I = 0; i < dmaltem->fDMACount; { 
dmaCurrent[iJ++; 
if (dmaCurrent[i] > 
dmattem->fDMAPossible[Q.fUpperDMAChannel) 

{ 

processDMA = FALSE; 
break; 

} else processDMA = TRUE; 

} 

} 

if (interruptltem ~ NIL) 
break; 

for (i = 0; 1 < interruptltem->flnterruptCount; 1++) { 
interruptCurTent[i]++; 
if (intentiptCurrent[i] > 

interruptltem->flnterruptPossible[i].fUpperlnterruptSocket) 

{ 

processinterrupt = FALSE; 
break; 

} else processinterrupt = TRUE; 
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} 

thisFunction.fHaveAssignment = FALSE; 
return TRUE; 

} 

5 

Boolean TIOResourceConflictResolver.:CheckAssignmentForConflict ( 
TIOResourceConflictResolver:FunctionPossibleAssignment& 
thisFunction, 
int currentlndex) 

10 { 

FunctionPosslbleAssignment *function; 

Boolean doesConfiict = FALSE; 

int i, count; 

// 

15 // Loop through each function, and check it against the current 

// function. Only those functions with assignments are checked. 

// 

// NOTE - on the first pass through, the Resolver is building 
// a list of conflicts, however, on subsequent passes, the scanning is 
20 // stopped earily when a conflict is found. This allows an early return 

// back to the previous routines to try another sequence. 
// 

function = &fFunctk)ns[0]; 
for (i = 0; I < fFuncttonCount; functlon-M-} { 
25 if (I ~ cunrentlndex) 

continue; 

if (function->fHaveAssignment == FALSE) 
continue; 

if (CheckMemoryAssignmentConflict(*function. thisFunction)) { 
30 if (fFirstPass == FALSE) 

return TRUE; 
doesConflict = TRUE; 

} 

if (CheckRegisterAssignmentConflict(^fijnction, thisFunction)){ 
35 if (fFirstPass == FALSE) 

return TRUE; 
doesConflict = TRUE; 

} 

if (CheckDMAAssignmentConflict(*function, thisFunction)) { 
40 if (fl=^irstPass == FALSE) 

return TRUE; 
doesConflict = TRUE; 

} 

if (ChecklnterruptAssignmentConflict(*function, thisFunction)) { 
45 if (fFirstPass = FALSE) 

return TRUE; 
doesConflict = TRUE; 
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} 

} 
// 

// Go to the next function, if possible 
// 

currentlndex++; 

if (cun-entlndex < fFunctionCount) { 

if (LoopThroughFunctionCcun-entlndex) == TRUE) 
return TRUE; 

} 

return doesConflict; 



Boolean TIOResourceConflictResolver::CheckMemoryAssignmentConflict ( 
TIOResourceConfliclResolver::FunctionPossibleAssignnr)ent& 
checkFunction, 

TIOResourceConflictResolver::FunctionPossibleAssignment& 
thisFunction) 

{ 

TIOFunctionResourceAssignment::TIOMemoryAssignment: 
BaseAddress thisMemoryAddress. memoryToCheckAddress; 

TIOFunctionResourceAssignment::TIOMenru>ryAssignment::BlockLength 
thisMemoryLength, memoryToCheckLength; 
MemoryAssignment ^thisMemory, ^checkMemory; 
int thislndex, checklndex; 

If (thisFunction.fMemoryCount == 0 1| checkFunction.fMemoryCount 

==0) 

return FALSE; 
Boolean doesConflict = FALSE; 

thisMemory = thisFunction.fMemoryAssignnnents; 
for (thislndex = 0; thislndex < thisFunction.^emoryCount; 
thislndex++, 

thisMenfK>ry+-i') { 
if (thisMemory->flsCardMemory == FALSE) 
continue; 

thisMemoryAddress = thisMemory->fBaseAddress; 
thisMemoryLength = thisMemory->fLength; 
checkMemory = checkFunction.fMemoryAssignments; 
for (checklndex = 0; checklndex < 

CheckFunction.fMemoryCount; checkl ndex++, 

checkMemory++) { 
if (checkMeniory->flsCardMeniory == FALSE) 

continue; 
memoryToCheckAddress = 

checkMemory->fBaseAddress; 
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memoryToCheckLength = checkMemory->fLength: 
If (thisMemory->fCanShare == FALSE || 

checkMemory->fCanShare == FALSE) { 
if ((thisMemoryAddress >= 

memoryToChecKAddress 
&& thisMemoryAddress < 

memoryToCheckAddress+ 
memoryToCheckLength) 
II (memoryToCheckAddress >= 
thisMemoryAddress 
&& memoryToCheckAddress < 
thisMemoryAddress+ 
thisMemoryLength)) { 

// 

// Only Create Conflicts on the first pass 
// 

if (fFirstPass) 

CreateResourceConflict(checkFunction, 
TIOResourceConflict::kMemoryRange); 
else return TRUE; 

doesConflict = TRUE; 

} 

) 

) 

} 

return doesConflict; 

) 

Boolean TIOResourceConflictResolvenrCheckRegtsterAssignmentConfiict ( 
TIOResourceConflictResolven:FunctionPossibleAssignment& 
checkFunctton, 

TIOResourceConflictResolven:FunctionPosslbleAssignment & 
thisFunctbn) 

{ 

TIOFunctk)nResourceAsstgnment:TIORegisterAssignment:: 
BaseAddress thisRegisterAddress, registerToCheckAddress; 
TIOFunctionResourceAssignmentrTIORegisterAssignment: 

BlockLength thisRegisterLength, registerToCheckLength; 
RegisterAssignmentnhlsRegister, *checkRegister, 
int thisindex, checklndex; 

if (thisFunction.fRegisterCount == 0 || checkFunctton.fRegisterCount 

==0) 

return FALSE; 
Boolean doesConflict = FALSE; 

thisReglster thisFunction.fRegisterAssignments; 



84 



W099A39268 



PCTAJS99/01740 



for (thislndex = 0; thislndex < thisFunction.fRegisterCount; 
thlslndex++, thisRegister*>-+) { 
checkRegister = checkFuncBon.fReglsterAssignments; 
thisRegisterAddress = thisRegister->fBaseAddress; 
thIsRegisterLength = thisRegister->fLength; 
for (checklndex = 0; checklndex < 

checkFunction.fRegisterCount; checklndex++, 

checkRegister++) { 

registerToCheckAddress = 

checkRegister->fBaseAddress; 
registerToCheckLength = checkReglster->fLength; 
If (thisRegister->fCanShare == FALSE i| 

checkRegister->fCanShare == FALSE) { 
if ((thisRegisterAddress >= 

registerToCheckAddress 
&& thisRegisterAddress < 
registerToCheckAddress^ 
registerToCheckLength) 
II (registerToCheckAddress >= 

thisRegisterAddress 
&& registerToCheckAddress < 
thisRegisterAddress* 
thisRegisterLength)) { 

// 

// Only Create Conflicts on the first pass 
// 

If (fFirstPass== FALSE) 

retumTRUE; 
CreateResourceConflict(checkFunction. 

TiOResourceConflict::klORange); 
doesConflict = TRUE; 

} 

} 

} 

} 

return doesConflict; 

} 



Boolean TIOResourceConflictResolverrCheckDMAAssignmentConflict ( 

TIOResourceConflictResoh^er::FunctionPossibleAssignment& 
checkFunction, 

TIOResourceConflictResolven:FunctionPossibleAssignment& 
thisFunction) 

{ 

Boolean doesConflict = FALSE; 

Int checklndex, thislndex; 
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DMAAssignment *checkDMA. *thisDMA: 

if (checkFunction.fDMACk)unt == 0 || thisFunction.fDMACount == 0) 

return FALSE; 
thisDMA = thisFunction.fDMAAssignments; 
for (thislndex = 0; thislndex < thisFunction.fDMACount; thislndex-i-i-. 
thisDI\4A-i-+){ 

checkDMA = checkFunction.fDMAAssignments; 
for (checklndex = 0; checklndex < checkFunction.fDMACount; 
checklndex++, checkDMA++) { 
if (checkDIVIA->fCanShare == TRUE && 
thlsDMA->fCanShare == TRUE) 
continue; 
if (thlsDMA->fDMAChannel == 

checkDMA->fDMAChannel) { 
if (fFirstPass== FALSE) 

return TRUE; 
CreateResourceConflict(clieckFunctlon. 

TIOResourceConflict::kDMA); 
doesConflict = TRUE; 

} 

} 

} 

return doesConflict; 

} 



Boolean TIOResourceConflictResoiven:Check!ntemjptAssignmentConflict( 
TIOResourceConflictResolven:FunctionPossibl^^ignment& 
checkFunction, 

TIOResourceConflictResolver.:Functk>nPossibleAssignment & 
thisFunction) 

{ 

Boolean doesConflict = FALSE; 

int thislndex. checklndex; 

IntemjptAssignment *thislntemjpt, *checklntenupt; 
if (checkFunctbn.flnterruptCount == 0 1| thIsFunction.flntenruptCount 

= 0){ 

return FALSE; 

} 

thislntemjpt = thisFunction.flntemjptAsslgnments; 
for (thislndex = 0; thislndex < thisFunction.flntenuptCount; 
thislndex-M-, thislnterrupt-f-f) { 
checklnterrupt = checkFunction.flntermptAssignments; 
for (checklndex = 0; checklndex < 

checkFunctlon.fintenxiptCount; 
checklndex-i"(-, checklntenupt-t-i-) { 
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if (thislntemjpt->fCanShare == TRUE && 

checkinterrupt->fCanShare == TRUE) { 
continue; 

} 

if (thislnterrupt->flntemjptSocket == 

checklnteiTupt->flntemjptSocket) { 
if (fFirstPass== FALSE) 
return TRUE; 
CreateResourceConflict 
(checkFunction, 

IOResourceConflict::klnterrupt); 
doesConflict = TRUE; 

} 

} 

} 

return doesConflict; 

} 

void TIOResourceConflictResolvenrCreateResourceConflict ( 

TIOResourceConfllclResolver:FunctfonPossibleAsslgnment& 

functionlnConflict, 
TIOResourceConflict::EResourceType resourceConflicting) 

TIOResourceConflict *newResourcelnConflict; 
TIOFunctionHardwarelnterfaceldentifier *id = 

::Copy(functionlnConfljct.fFunctionldentifter) 

» 

newResourcelnConflict = new TIOResourceConflict; 

newResourcelnConflict->SetResourceType(resourceConflicting): 

newResourcelnConfllcl->SetConflictType(fConfliclType); 

newResourcelnConflict->SetResourcelndex(0); 

newResourcelnConflict->SetFunctlonidentiflert*id): 

if (functionlnConfllctfConflicts == NIL) 

functionlnConflictfConflicts = new 
TDequeOf<TIOResourceConflict>; 

functionlnConfliclfConflicts->Add(newResourcelnConfllct); 



voidTIOResourceConflictResolven:ConstructNewAsslgnment( 

TIOResourceConflictResolven:Functk>nPos8lbleAssignment& 

thisFunction. 

TIOResourceConflictResolver:interruptCollection *intemjptltem, 
TIOResourceConfllctResolven:DMACollection *dmaltem. 
nOResourceConfilclResolver :ReglsterCollection *reglsterltem. 
TIOResourceConfllctResolver.:MemoryCollection*memoryltem) 

// Construct an assignment 
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// based on the current possible, and values 
// 

TIOFunctionResourceAssignment ^newAssignment = new 
TIOFunctionResourceAssignment; 

int i; 

thisFunction.fConstructedAssignment = newAssignment; 
if (interruptltem) { 

TDequeOf<TIOFunctlonResourceAssignment:: 
TlntemjptAsslgnment> InterruptDeque; 
TIOFunctionResourceAssignment::TlntenruptAsslgnment 

*interruptAsslgnment; 
for (I = 0; I < intemjptltenr>->flntemjptCount; { 
InterruptAssignment = new 

TIOFunctionResourceAssignment:: 
TlnterruptAssignment; 
intenruptAssignment->SetSharability( 

interruptltenr)->lnterruptPossiblep].fCanShare); 
interruptAsslgment-> 

SetlnterruptSocket(thisFunction. 
flntemjptAssignments[Q.flntenruptSocket): 
interruptAssignment-> 

SetlnterruptUsageMode( 
interTuptltem->flnterruptPossible[i]. 

flnterruptMode); 
ihterruptAssignment->SetConstraintNumber 

interruptltern-> 

flntemjptPossible[Q.fConstralnt); 
intenuptDeque.Add(interruptAssignnrient); 

} 

newAssignment->SetlnterruptAssignment(interTuptDeque); 
interruptDeque.DeleteAIIO; 

} 

if(dmaltem){ 

TDequeOf<TiOFunctionResourceAssignment:: 

TDMAAssignment> 
dmaDeque; 
TIOFunctionResourceAssignment:: 

TDMAAssignment ^dmaAssignment; 
for (1 = 0; i < dmaltenv>fDMACount; { 
dmaAssignment = new 

TIOFunctionResourceAssignment:: 

TDMAAssignment: 
dmaAssignment->SetSharability(dmaltenv> 
fDMAPossible[Q.fCanShare); 
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dmaAssignment->SetChannelNumber(thisFunction. 

fDMAAssignments[i].fDMAChannel); 
dmaAssjgnment->SetDMAUsageMode(dmaltem-> 

fDMAPossiblepl.fDMAMode); 
dmaAssignment->SetConstraintNumber(dmaltem-> 

fDMAPossible[q.fConstraint); 
dmaDeque.Add(dmaAssignment); 

} 

newAssignment->SetDMAAssignment(dmaDeque); 
dmaDeque.DeleteAIIO; 

} 

if (memoryltem) { 

TDequeOf<TIOFunctionResourceAssignment:: 
TIOMemoryAssjgnment> memoryDeque; 

TIOFunctionResourceAssignment::TIOMemoryAssignment 

"^memoryAssignment; 
for (i = 0; i < memoryltem->fMemoryCount; { 
memoryAssignment = new 

TIOFunctbnResourceAssignment: : 

TiOMemoryAssignment; 

rnernoryAssignment->SetSharability(memoryltem-> 

fMemoryPossible[q.fCanShare); 
rnemoryAssignment->SetBaseAddress(thisFunction. 

fMemoryAssignments[q.fBaseAddress); 
mernoryAssignment->SetLength(memoryitern-> 

fMemoryPossible[q.fLength); 
memoryAssignment-> 

SetMemoryUsageMode(memoryltem-> 

fMemoryPossible[q.fMemoryMode); 
memoryAssignment->SetConstraintNumber( 

memoryltem->fMernoryPossible[l].fConstrajnt); 
memoryDeque.Add(menioryAssignment); 

} 

newAssignment->SetMemoryAssignment(memoryDeque); 
memoryDeque.DeleteAIIO; 

} 

if (registerltem) { 

TDequeOf<TIOFunctionResourceAssignment:: 
TIORegisterAssignment> registerDeque; 
TiOFunctionResourceAssignmentrTIORegisterAssignment 

^registerAssignment; 
for (i = 0; i < registerltenv>fRegisterCount; { 
registerAssignment = new 

TIOFunctionResourceAssignment:: 

TIORegisterAssignment; 



89 



W099A39268 



PCTAJS99/01740 



registerAssignment->SetSharability(registerltem-> 

fRegisterPossible[i].fCanShare); 
registerAssignment->SetBaseAddress( 

thisFunction. fRegisterAssignments[i]. 
fBaseAddress); 
registerAssignment->SetLength(registerltem-> 

fRegisterPossible[i].fLength}; 
registerAssignment-> 

SetConstraintNumber(registerltem-> 
fRegisterPossible[i].fConstraint); 
registerAssignment-> 

SetRegisterUsageMode(registerlteni-> 
fRegisterPossible[il.fRegisterMode); 
registerDeque.Add(registerAssignment); 

} 

newAssignment->SetlOAsslgnment(registerDeque); 
registerDeque.DeleteAIIO; 

} 

return; 

} 

Boolean TIOResourceConflictResolver:lsAsslgnmentV\rithinPlatf^ 

TIOResourceConflictResdverDoerrFunctionPDSsibleAssignme^^ 
function) 

{ 

return (IsMenfK)ryAssignmentWrthinLimits(function)) 
&& (IsRegisterAssignmentWithinlJmits(fijnction)) 
&& (lsDMAAssignmentWithinLlmits(function)) 
&& (lslntenruptAssignmenW\rrthinLimits(function)); 

} 

Boolean 

TIOResourc»Confii<^esolverDoen:lsMenrK)iyAssignmentWithinL^ 

TIOResourceConfiictResolverDoen:FunctionPossibleAssignment& 
function) 

{ 

TIOFunctionResourceAssignment::TIOMemoryAssignment:: 
BaseAddress thisMemoryAddress, memoryToCheckAddress; 
TIOFunctionResourceAssignment::TIOMemoryAsslgnment: 
BlockLength thisMemoryLength, memoryToCheckLength; 
MemoryAssignment *thisMemory, ^checkMemory; 
int thtslndex, checklndex; 

If (function.fMemoryCount == 0 || fMemoryLimitCount == 0) { 
return TRUE; 

} 

thtsMemory = function.fMemoryAssignments; 
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for (thislndex = 0; thislndex < function.fMemoryCount; thlslndex++, 

thisMemory++) { 
iff (thisMemory.>flsCardMemory == FALSE) 
continue; 

thisMemoryAddress = thisMemory->fBaseAddress; 
thisMemoryLength = thisMeniory->fLength; 
checkMemory = fMemoryLimit; 
ffor (checklndex = 0; checklndex < fMemoryLimltCount; 

checklndex++, 

checkMemory++) { 
Iff (checkMemory->flsCardMemory == FALSE) 

continue; 
memoryToCheckAddress = 

checkMemory->fBaseAddress; 
memoryToCheckLength = checkMemory->fLength; 
Iff ((thisMemoryAddress >= memoryToCheckAddress 
&& thisMemoryAddress < 

memoryToCheckAddress-i-memoryToCheckLength) 
&& (memoryToCheckAddress >= thisMemoryAddress 
&& memoryToCheckAddress < 

thisMemoryAddress+thisMemoryLength)){ 

return TRUE; 

} 

} 

} 

return FALSE; 

} 

Boolean TIOResourceConflictResolver:lsRegisterAssignmentWithinLimits( 
TIOResourceConflictResolver:Functk>nPossibleAssignment & 
function) 

{ 

TIOFunctionResourceAssignment::TIORegisterAssignment:: 
BaseAddress thisRegisterAddress. registerToCheckAddress; 
TIOFunctionResourceAssignmentrTIORegisterAssignment: 
BlockLength thisRegisterLength. registerToCheckLength; 
RegisterAssignment*thisReglster,*checkRegisten 
int thislndex. checklndex: 

Iff (function.fRegisterCount == 0 1| fReglsterLimitCount = 0) { 
return TRUE; 

} 

thisRegister = function.fRegisterAssignments; 
ffor (thislndex = 0; thislndex < function.fRegisterCount; thislndex++, 
thisRegister++) { 

thisRegisterAddress = thisRegister->fBaseAddress: 
thisRegisterLength = thisRegister->fLength; 
checkRegister = fRegisterLimlt; 
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for (checklndex = 0; checklndex < fReglsterLimitCount; 

checklndex->-+,checkRegister++) { 
registerToChecKAddress ~ 

checkRegister->fBa8eAddres8; 
registerToChecRLength = checkRegister->fLength: 
if ((thisRegisterAddress >= registerToCheckAddress 
&& thisRegisterAddress < 

reglsterToCheckAddress+registerToCheckLength) 
&& (registerToCiieckAddress >= thisRegisterAddress 
&& registerToCheckAddress < 

thisRegisterAddress-i-thisRegisterLength)){ 

return TRUE; 

} 

} 

} 

return FALSE; 

} 

Boolean TIOResourceConflictResolver:lsDMAAsslgnmentWithinLimits( 

TIOResourceConfiictResolver:FunctionPossibleAssignment & 
fundion) 

{ 

int thislndex. checklndex; 

DMAAssignment *thisDIVIA: 
DMAPossible *checkDMA; 
if (fiinction,fDMACount == 0 |i fDMALimitCount == 0) { 
return TRUE; 

} 

thisDMA = function.fDiyAAAssignments; 

for (ttiislndex = 0; thislndex < function.fDMACount; thislndex++. 

thisDMA++){ 

checkDMA = fDMALimit; 

for (checklndex = 0; checklndex < fDMALimitCount; 
ched(lndex++. checkDMA+-<-) { 
if (thisDMA-XDMAChannel <= 

checkDMA->fLowerDMAChannel 
&& thisDMA->fDMAChannel >= 
checkDMA->fUpperDMAChannel) { 
return TRUE; 

} 

} 

} 

return FALSE; 



Boolean TIOResourceConflictResolver:lslntemiptAssignmentWithinUmrts( 
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TIOResourceConfllctResolven:FunctionPossibleAssignment& 
function) 

{ 

int thislndex, checklndex; 

lntenuptAssignment*thislnterrupt; 
IntenuptPossible *checklntenrupt; 
Iff (fLinction.flntemjptCount == 0 || fInterruptLimitCount == 0) { 
return TRUE; 

} 

thislntermpt = function.finterruptAssignments; 
ffor (thislndex = 0; thislndex < function.flnteiruptCount; thislndex++, 
thislnterrupt++) { 
checklnterrupt = flnteniiptLimit; 
ffor (checklndex = 0; checklndex < flntenruptLimitCount; 
checklndex++. checklntemjpt++) { 
iff (thislntemjpt->flnteraiptSocket >= 

checklntenrupt->fLowerintermptSocket 
&& thlslnterrupt->flntemjptSocket <= 

checklntenupt->fUpperintemjptSocket) { 
return TRUE; 

} 

} 

} 

return FALSE; 

} 

void TIOResourceConflictResolver.:UpdateCardsFromFunctionCollection() 

TDequeOf<TIOFunctionResourceUsage> functionDeque; 
TIOFunctionResourceUsage *function; 
TSequenceOmerator<TIOFunctionResourceUsage> *functionlterator, 
TIOCardResourceUsage *card; 
TSequenceOflterator<TIOCardResourceUsage> *cardlteiraton 
TAn^yOf<FunctionPossibleAssignment> 

orderedFunctions; 
int functionlndex; 
FunctionPossibleAssignment ^newFunction; 
// 

// Reconstruct the function Collection in the proper order 

// 

orderedFunctlons.SetAutoGrowFlagfTRUE); 

ffor (functionlndex = 0; functionlndex < fFunctionCount; 

functionlndex++) 
orderedFunctions.AtPut(fFunctjons[functionlndex]. 
fFunctionlndex,&fFunctions[functionlndex]); 
cardlterator = fCard.CreateSequencelterator(); 
ffor (funcHonlndex = 0. card = cardIterator->First();card != NIL; card = 
cardlterator->Next()) { 
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card->GetFunctionResourceUsage(functionDeque); 
functionlterator = functionDeque.CreateSequencelterator(); 
for (function = functionlterator->First(); function != NIL; 
function = functionlterator->Next()) { 
if (functionlndex >= fFunctionCount) 

// Throws Exception - Internal En^on* 
throw (TConflictResolverException( 

TConflictResolverException::klntemalError)); 
newFunction = orderedFunctions.At(functionlndex); 
if (newFunction == NIL) { 
throw newFunction; 

} 

if (newFunctlon->fHaveAssignment && 

newFunction->fConstructedAssignment) { 
function->SetAssignment(^newFunction-> 
fConstnictedAssignment); 
} else if (newFunction->fConflicts) { 

function->SetResourceConflicts(*newFunction-> 

fConflicts); 

} 

if (newFunction->fConflicts) { 

newFunction->fConflicts->DeleteAII(); 
delete newFunction->fConflicts; 

} 

if (newFunction->fConstnjctedAssignment) 

delete newFunctjon->fConstmctedAssignment; 
if (newFunction->fDMAChannelNumbers) 

delete newFunction->fDMAChannelNumbers; 
If (newFunction->flntermptSocketNumber5) 

delete newFunction->flnterruptSocketNumt)ers; 
if (newFunctton->fRegisterBaseAddresses) 

delete newFunction->fRegister6aseAddresses; 
if (newFunctton->fMemoryBaseAddresses) 

delete newFunction->fMemoryBaseAddresses; 
RennoveConstaictedAssignments(^newFunction); 
delete newFunctk)n->fFunctionldentifier 
functk>nlndex-t'+; 

} 

card->SetFunctionResourceUsage(functionDeque); 
delete functionlterator, 
functionDeque.DeleteAIIO; 

} 

if (functionlndex != fFunctionCount) { 
// throws exceptbn 
throw (TconflictResolverException( 

TconflictResolverException::klntemalEnror)); 
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delete cardlterator; 
delete fFunctions; 
fFunctionCount = 0; 

} 

5 

voidTIOResourceConflictResolven:RemoveConstructedAssignments( 
TIOResourceConfliclResolver:FunctionPossibleAssignment& 
function) 

{ 

10 if (function.fMemoryAssignments) { 

function.fMemoryCount = 0; 
delete function.fl^emoryAssignments; 
function.fMemoryAssignments = NIL; 

} 

15 if (function .fRegisterAssignments){ 

function.fRegisterCount = 0; 
delete function. ff^egisterAssignments; 
funcdon.fRegisterAssignments = NIL; 

^ } 

20 if (fiinction.fDMAAssignments) { 

function.fDMACount = 0; 
delete functlon.fDMAAssignments; 
function.fDMAAss^nments = NIL: 

) 

25 

if (function.flntemjptAssignments) { 
function.flntenruptCount = 0; 
delete function.flntenruptAssignments; 
function.fintenruptAssignments = NIL; 

30 } 
} 

4. The Resource Lock Class 

The TIOFunctionResourceUsage class 1104 further includes a class 

35 which can be used, in accordance with the principles of the present invention, 
to control access to shared resources after a resource assignment has been 
made. This class is the TIOResourceLockEntry class 1 106 which includes a 
GetResourceAssignmentO method that is used to retrieve the conflict-free 
resource assignments for an I/O function and an Acquire() member function 

40 that is used to access the assigned resources. The Acquire() method calls a 
private method (AcquireResourceLock()) , described above in connection with 
the lOFunctionResourceUsage object created from class 1 104, which method 
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attempts to acquire a semaphore lock (of type TRecoverableSemaphore) in 
the lOFunctionResourceUsage object to the resources assigned to the 
corresponding I/O function. The Acquire() method Includes a parameter 
(EAccessMode) which indicates whether the client requiiBs exclusive or 
shared access to the resource assignment The lock is acquired only once 
and an exception is thrown If a predetenmined period of time expires before 
the lock Is acquired. The exception identifies the holder(s) of ttie lock. The 
AcquireO method has the following code: 

void Acquire (const TIOFunctionHardwarelnterfaceldentjfier& function, 
const EAccessMode mode, const TTime& maximumWait) 

{ 

TIOFunctionResourceUsage *functionltem; 

If ((functionltem = FIndFunctionBylD (W)) == NIL) { 

throw (TConflKtResolverException 

(TCkxiflKtResolverException-kFunctionNotRegistered)): 
return; 

} 

functionltefTv->AcquireResourceLock(mode. maximumWait); 

) 

Thus, to access the resources for an I/O function, clients instantiate a 
lOResourceLockEntry object from the TIOResourceLockEntry class 1 106 and 
call the AcquireO method of the object. It should be noted that instantiation of 
the lOResourceLockEntry object alone does not implicitly acquire the lock. 
However, destruction of the lOResourceLockEntry object does implicitiy 
release the resources acquired by the lOResourceLockEntry object. 

The TIOResourceLockEntry dass 1 106 also includes a 
GetResourceAssignment() method which retrieves a resource assignment for 
an I/O function via the lOFunctionResourceUsage object. The 
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GetResourceAssignmentO method can be called after the resource lock is 
acquired by means of the Acquire() method and obtains the conflict-free 
resource assignment for an I/O function. The resources can be used only by 
the task which calls the Acquire() method or by interrupt handlers which have 
5 been registered in the I/O resource conflict resolver by the 

AddlnterruptHandlerReferenceO and RemovelnterruptHandlerReference() 
methods, if resources are not assigned to an I/O function, the 
GetResourceAssignmentO method throws an exception. The 
GetResourceAssignmentO method has the following form: 

10 

void GetResourceAssignment ( 

TIOFunctionResourceAssignment& function) const; 



As mentioned above, resources may be assigned to an I/O function on 

15 an expansion card even if the expansion card is not physically installed. A 
conresponding device driver must verify that the hardware is physically 
installed in the expansion slot t>efore using the resources. The 
GetResourceAssignmentO method retrieves the resource assignments from 
an object created from the TIOFunctionResourceAssignment class 1 108. 

20 which is the representation of the conflict-free resource assignment created 
for an I/O function. An lOFunctionResourceAssignment object is instantiated 
from the TIOFunctionResourceAssignment dass 11 08 and encapsulates 
resource assignment infomiation such as memory, I/O registers, intenrupt 
sockets, and DMA channel assignment This dass includes several nested 

25 classes which encapsulate the various assignments. These nested dasses 
are discussed in more detail in connection with Figure 15. In order to retrieve 
resource assignments, device driver dients create lOResourceLockEntry 
objects and retrieve an lOFunctionResourceAssignment object through the 
lOResourceLockEntry object thus created. The 

30 TIOFunctionResourceAssignment dass 1 108 is a monomorphic dass which 
is normally not subdassed by developers. 
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The TIOFunctionResourceAssignment class 1 108 includes a 
GetMemoryAssignmentO member function which reads memory ranges from 
the object for a particular resource assignment and a 
SetMemoryAssignmentO member function which writes the memory ranges in 
the object for the resource assignment. A GetlOAssignment() member 
function and a SetlOAssignment() member function respectively read and 
write the I/O ranges for this assignment in the object. 

A GeneratelntermptO method returns a first boolean value (e.g. TRUE) 
if the corresponding I/O function generates an interrupt to the processor and 
a second boolean value (e.g. FALSE) if the I/O function does not generate an 
interrupt to the processor. A GetlnterruptAssignment() returns information 
about an intenrupt socket for this assignment and a SetlnterruptAssignment() 
method writes the information about the interrupt socket for this assignment. 

A NeedsDMAChannelO method returns a first boolean value (e.g. 
TRUE) if the I/O functbn on the corresponding expansion card requires a 
DMA channel and a second boolean value (e.g. FALSE) if it does not. A 
GetDMAAssignmentO method returns DMA channel assignment infomiatfon 
for a particular resource assignment and a SetDMAAssignment() writes 
information about the DMA channel for the particular resource assignment. 

The lOResourceLockEntry object is also responsible for managing 
resources assigned to an I/O function when that function dies. In order to 
perfomn this management function, device driver clients register a 
TInterruptHandlerReference with the lOResourceLockEntry object so that the 
object can free the resources assigned to the conresponding I/O functions 
automatically when the functions are temiinated. The 
TIOResourceLockEntry dass is a monomorphic dass which is nomially not 
subdassed by developers. The TIOResourceLockEntry dass 1 106 also 
indudes a RemoveintenuptHandlerReference() method which de^registers 
the intenrupt handler reference previously registered by the 
AddlntemjptHandlerReferenceO method. The 
AddlnterruptHandlerReferenceO method has the following form: 
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void AddlnterruptHandlerReference (const TinterruptHandlerReference& 

interruptHandler); 



5. The Resource Conflict O bject and Resource Assignment Classes 

In accordance with the principles of the invention, the 
TIOResourceConflict class 1110 encapsulates infomriation explaining why a 
particular I/O function could not be assigned its required resources. The 
TIOResourceConflict class 1110 encapsulates information such as which 
resource is the conflicting resource, which assignment period is the conflicting 
assignment period (current boot or next boot) and the conflicting resource's 
index in a resource collection. Whenever a conflict in resource assignment is 
encountered while creating conflict-free assignment for an I/O function, the 
resource conflict resolver instantiates an lOResourceConflict object from the 
TIOResourceConflict class 1110. When the conflict is removed and a 
conflict-free resource assignment is produced, the lOResourceConflict object 
which was instantiated is subsequently deleted intemally by the resource 
conflict resolver object. The TIOResourceConflict dass is a monomorphic 
dass which is normally not sul)dassed by devebpers. 

The TIOResourceConflict dass 1110 indudes the typical constnjctor 
and destructor member functbns and also indudes a plurality of unique 
member functions. For example, the TIOResourceConflict dass 1110 defines 
a private attribute which stores an enumerated resource type 
(kMemoryRange, klORange. kinteraipt or kDMA.) A GetResourceType() 
member functbn reads the type of resource which type indicates the 
existence of conflicts in a particular type of resources. A SetResourceType() 
member function writes the type of resource to the private attribute. 

The TIOResourceConflict class 1110 also defines a private attribute 
which stores an enumerated conflict period designator (kConflictNow or 
kConflictAflerBoot) The GetConfliclType() member function reads the type of 
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conflict from the private attribute and returns first type (kConfllctNow) if the * 
conflict will occur for the current boot period and the second type 
(kConfiictAfterBoot) if the conflict will remain even after this boot period. A 
SetConflictTypeO member function writes the type of conflict to the private 
5 attribute. 

A GetResourcelndexO member function of the TIOResourceConflict 
class 1 100 reads the resource index of the resource over which the conflict 
occured (the index Identifies the particular resource in a collection of 
resources) firom a private attribute while a SetResourcelndex() member 

10 function writes the index into the private attribute. This index allows a method 
which processes the resource conflict object to identify the particular resource 
which caused the conflict. 

A SetFunctionldentifierO member function writes the 
THardwarelnterfaceldentffier value for a conflicting I/O function into a private 

1 5 attribute in order to identify the function which caused the conflict. 

The TPossiblelOResourceAssignment dass 1112 is an encapsulation 
of possible choices (and constraints) in resource assignments for an I/O 
function. The possible choices and constraints are obtained, as discussed 
above, from either the board itself (in the case of auto-configure expansion 

20 boards) or from a database (in the case of a manually-configurable expansion 
board.) 

A PossibielOResourceAssignment object instantiated from the 
TPossiblelOResourceAssignment dass 1112 encapsulates resource 
assignment information induding, but not limited to, possible assignment of 
25 memory ranges, I/O register ranges. Interrupt sockets or request lines, 
interrupt priority levels and DMA channels. The 

TPossiblelOResourceAssignment dass 11 12 is a monomorphic class which 
is normally not subdassed by developers. It Includes several nested 
constraint dasses which are explained in more detail in connection with 
30 Figure 16 below. 

The TPossiblelOResourceAssignment dass 1112 includes a plurality 
of member functions Induding the typical constructor and destructor 
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functions. Thie TPossiblelOResourceAssignment class 1112 also includes 
several methods for getting and setting constraints which are encapsulated in 
the nested constraint objects. These member functions include a 
GetMemoryConstraintsO method and a SetMemoiyConstraints() method for 
respectively reading and writing constraints in memory usage in a collection 
of nested lOMemoryConstraint objects. 

Similarly, a GetlOConstraints() method and a SetlOConstraints() 
method respectively read and write constraints in I/O register usage in a 
collectoin of nested lORegisterConstraint objects. 

A GetlnterruptConstraintsO method and a SetlnterruptConstraints() 
method 

respectively read and write constraints in inteniipt socket usage in a 
collection of lOlnterruptConstraint objects, while a GetDMAConstraints() 
method and a SetDMAConstraints() method respectively read and write 
constraints in DMA channel usage in a collection of lODMAConstraint objects. 

Refem'ng now to Figure 15, the conflict resolver framework further 
includes a set of resource assignment classes. These classes include 
classes which are nested within a TIOFunctionResourceAssignment class 
1508 mentioned above in conjunction with Figure 11. The nested classes 
include a TInterruptAssignment dass 1502, a TIOMemoryAssignment dass 
1500, a TIOMemoryUsageMode class 1506, a TIORegtsterAssignment dass 
1512, a TDMAAssignment dass 1510 and a TDMAUsageMode dass 1514. 

The TInterruptAssignment class 1502 encapsulates information atx)ut 
the Interrupt socket assigned to an individual I/O function. The 
TlntenuptAssignment dass 152 is a monomorphic dass which Is normally not 
subdassed and indudes a plurality of unique member functions such as a 
GetlnterruptSocketO method which reads the intenrupt socket number for an 
I/O function from a private attribute and a SetlntenruptSocket() method writes 
the interrupt socket number for the I/O function into the private attribute. 
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A GetParentlnterruptHandlerReferenceO method and a 
SetParentlnterruptHandlerReferenceO method respectively read and write the 
parent Interrupt handler for an I/O function into a private attribute. 

A GetlnterruptUsageModeO method and a SetlntemJptUsage^4ode() 
method respectively read and write the usage mode for the interrupt socket 
used by the I/O function into a private attribute. An lsSharable() method 
returns a first value (e.g. boolean TRUE) if an Inteniipt socket used by the I/O 
function can be shared by other I/O functions and a SetSharabilityO method 
writes the shareability for the I/O function into a private attribute. 

The TIntenruptAssignment dass 1502 is associated with a 
TlntemiptUsageMode dass 1504 which encapsulates information about the 
characteristics of the specified intenrupt socket The TlntemiptUsageMode 
dass 1504 is a monomorphic dass which is nomnally not subdassed by 
developers. 

The TIntenruptUsageMode dass 1504 also indudes a plurality of 
member functions induding a GetSocketType() method reads, from a private 
attribute, an enumerated socket type of the socket and returns a first value 
(kEdge) if the socket is an edge type socket and a second different value 
(kLevel) if the socket is a level type socket. A SetSocketType method writes 
the socket type to the private attribute. 

A GetSocketStateO method reads the socket state from a private 
attribute and returns a first value (kHigh) for a level high, or edge high, type 
and a second different value (kLow) for a level low, or edge low. type of 
socket A SetSocketStateQ method writes the socket state to the private 
variabte. 

The TIOMemoryAssignment dass 1500 is a representetion of a 
memory range assigned to an individual I/O function and is nested inside the 
TIOFunctbnResourceAssignmentdass 1508. The TIOMemoryAssignment 
dass 1500 is a monomorphic dass and is nomnally not subdassed by 
developers. The TIOMemoryAssignment dass 1500 indudes a plurality of 
member functtons indudiing the GetBase/^ress() method reads a base 
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address from a private attribute for an assigned memory range and a 
SetBaseAddressO method writes the base address for the memory range. A 
GetLengthO method reads the length of the assigned memory range and a 
SetLengthO method writes the length of the assigned memory range into a 
5 private attribute. A GetMemoryUsageMode() method and a 

SetMemoryUsagelModeO method respectively read and write the usage mode 
for the assigned memory range into a private attribute. 

An IsSharableO method retums a first value (e.g. a boolean TRUE 
value) from a private attribute if a memory range used by the I/O function can 
10 be shared by other I/O functions. A SetSharabilityQ method writes the 
shareability for the I/O function. 

The TIOMemoryAssignment class 1500 is associated with a 
TIOMemory UsageMode dass 1506. The TIOMemoryUsageMode class 
1506 encapsulates information about the usage of a specified memory range. 
15 TIOMemoryUsageMode dass 1506 is a monomorphic dass which is normally 
not subdassed by developers. 

The TIOMemoryUsageMode dass 1506 incudes a 6etAccessMode() 

method which reads an access mode for the memory range from a private 

attribute and retums a first value (kReadOnly) if the memory is read only 
20 memory (ROM) and a second different value (kWritable) if the memory is 

random access memory (RAM). A SetAccessMode() method writes the 

access mode for the memory range. 

A GetAccessSizeO method reads the access size for the memory 

range from a private attribute and retums an indication as to whether the 
25 menrory range is accessible as an 8 bit. a 16 bit, both an 8 bit and a 16 bit or 

a 32 bit memory range. A SetAccessSize() method writes the access size for 

the memory range. 

The TIORegisterAssignment dass 1512 is the representation of an I/O 
register range assigned to an individual I/O function and is a monomorphic 
30 class which is nested inside the TIOFunctionResourceAssignment class 
1508. The TIORegisterAssignment dass 1508 indudes the typical 
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constructor and destructor member functions as well as a plurality of unique 
member functions. For example, a GetBaseAddress() method and a 
SetBaseAddressO method respectively read and write the base address for a 
particular I/O register range. A GetLength() method reads the length of the 
I/O register range and a SetLength() method writes the length of the I/O 
register range. An lsSharable() method retums a first value (e.g. Boolean 
TRUE) if an I/O register range used by the I/O function can be shared by 
other I/O functions and a SetSharability() method writes the sharability for the 
I/O function. 

A TDMAAssignment class 1510 encapsulates infonnation about a 
DMA channel assigned to an individual I/O function. The TDMAAssignment 
dass 1 51 0 is a monomorphic dass which is nested inside the 
TIOFunctionResourceAssignment dass 1508. The TDMAAssignment dass 
1 51 0 is normally not subdassed by developers. The TDM/^/^ignment dass 
1510 indudes a plurality of unique member functions. For example, a 
GetChannelReference() method and a SetChannelReferenceO method 
respectively read and write a reference to a DMA channel handle. A 
GetDMAUsageModeO method and a SetDMAUsageMode() method 
read from a private attribute and write to the private attribute the usage mode 
for the DMA channel. An lsSharable() method retums a first value (e.g. 
boolean TRUE) fifom a private attribute if the DMA channel used by the I/O 
function can be shared by other I/O functions and a SetSharabilityO method 
writes the sharability for the I/O function to the private attribute. 

The TDMAAssignment dass 1 51 0 is associated with a 
TDMAUsageMode dass 1514 which encapsulates information about the 
usage of a specified DMA channel. The TDMAUsageMode dass 1514 is a 
monomorphic class which is normally not sut)dassed by developers and 
indudes a plurality of member functions induding a GetTransferSize() method 
which reads the size of a single data transfer unit firom a private attribute and 
retums a parameter having a predetermined value to indicate whether an 8- 
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bit. 16-bit, 32-bit or 8/16 bit transfer is taking place. A SetTransferSize() 
method writes the transfer size. 

A GetCountingModeO method of class 1514 reads the mode for 
counting the data transfer units. The method retums a first value 
5 (kCountByByte) if counting is done on a byte-by-byte basis and a second 
different value (kCountByWord) if counting is done on a word-by-word basis. 
Similarly, a SetCountingMode() method of TDMAUsageMode class 1 514 
writes the mode for counting the transfer units into a private attribute. A ' 
GetTransferSpeedO method reads the timing information for the transfer from 
10 a private attribute and retums enumerated indicators (e.g. kISACompatlble, 
kTypeA, kTypeB, kTypeC or kTypeF) to indicate if the I/O function uses ISA 
compatible timing, Type A timing. Type B timing. Type C timing or Type F 
timing respectively. A SetTransferSpeed() method writes timing infomiation 
for the transfer into the private attribute. 

15 A GetTransferModeO method reads the transfer mode used by the I/O 

function. The GettTransferModeQ method retums an enumerated value (e.g. 
kSingle, kBIock or kDemand) rf the I/O function uses single transfer, block 
transfer or demand mode transfer, respectively to indicate the transfer mode 
used by the I/O function. A corresponding SetTransferMode() method writes 

20 the transfer mode for an I/O function into a private attribute. A 

GetBusAccessModeQ method retums a first enumerated value (kMaster) from 
a private attribute if an I/O fiinctbn is a bus master and a second different 
value (kSlave) if the I/O function is not a bus master. A SetBusAccessMode() 
method writes the master or slave attribute for an I/O function to the private 

25 attribute. 

Referring now to Figure 16, the conflict resolver framework includes a 
plurality of constraint classes which are nested in the 
TPossiblelOResourceAssignment class 1608 also described above in 
conjunction with Figure 1 1 (class 1110) These classes are also associated 
30 with the TlOMemoryUsageMode dass 1606, the TInterruptUsageMode class 
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1610 and the TDMAUsageMode classes 1616 described above in conjunction 
with Figure 15. 

As can be seen in Figure 16, the TPossibielOResource Assignment 
dass 1608 has nested constraint classes including a TIOMemoryConstraInt 
5 dass 1600, a TIORegisterConstraint dass 1602, a TInterruptConstraint dass 
1612 and a TDMAConstraint dass 1614. 

The TIOMemoryConstraInt class 1600 is the representation of 
constraints in the usage of memory ranges used by an individual I/O function, 
induding memory locations and lengths. The TIOMemoryConstraInt dass is a 
10 monomorphic dass which is nomnally not subclassed by developers. The 
TIOMemoryConstraInt dass 1600 indudes a plurality of member functions 
induding a GetLength() method and a SetLength() method which read and 
write, respectively, the length of a memory range in a private attribute. 

A GetLowerBaseAddressO method reads the lowest base address of a 
15 memory block that can be assigned to an I/O function and a 

SetLowerBaseAddress method() writes the lowest base address of the 
memory block that can be assigned to an I/O function to a private attrbiute. 

Similariy, a GetUpperBaseAddress() method reads the highest base 
address of a memory block that can be assigned to an I/O function and a 
20 SetUpperBaseAddressO writes the highest base address of the memory block 
that can t>e assigned to an I/O function to a private attribute. 

A GetBaselncrementO method reads a predetermined increment value 
for a base address and a SetBaselncrement() method writes a base 
increment value for a base address to a private attribute. 

25 An IsSharableO method retums a first value from a private attribute 

(e.g. a boolean TRUE) if a memory range used by an I/O function can be 
shared by other I/O functions and a SetSharabilityO method writes the 
sharability value for the I/O function to the private attribute. In a like manner, 
a GetMemoryllsageModeO method reads the usage mode of the memory 

30 range and a SetMemoryUsageMode() writes the usage mode of the memory 
range to a private attribute. 
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* The TIORegisterConstraint class 1602 repreisents constraints in the 
usage of I/O register ranges by an Individual I/O function. The 
TIORegisterConstraint dass 1602 is a monomorphic class which is nested 
inside the TPossiblelOResourceAssignment class 1608. 

5 The TIORegisterConstraint class 1602 includes a plurality of member 

functions for specifying constraints on I/O register ranges including a 
GetLengthO method which reads the length of an I/O range and a 
SetLengthO method writes the length of an I/O range from a private attribute. 
A GetLowerBaseAddressO method and a GetUpperBaseAddress() method 

10 respectively read the lowest and highest base addresses of the I/O block that 
can be assigned to an I/O function from a private attribute. A 
SetLowerBaseAddressO method and a SetUpper6aseAddress() method write 
respectively the lowest and highest base addresses of the I/O block that can 
be assigned to an I/O function to the private attribute. 

15 The class 1602 further includes a GetBaselncrement() method and a 

SetBaselncrementO method which respectively read and write a base 
increment value for the base address to another private attribute. An 
IsSharableO method returns a first value (e.g. boolean TRUE) from an 
addittonal private attribute if the I/O range used by the I/O function can be 

20 shared by other I/O fiinctbns and a SetSharability() method writes the 
sharability for the I/O function in the private attribute. 

The TlnterruptConstraint dass 1612 encapsulates information ahoxA 
resource constraints in the usage of an interrupt socket by an individual I/O 
function. The TIntenuptConstraint dass 1612 is a monomorphic dass which 

25 is nested inskJe the TPosslblelOResource/Kssignment dass 1 608 and is 
normally not subdassed by developers. 

The TIntenruptConstraint dass 1612 indudes a 
GetParentlnterruptHandlerReferenceO method which reads the reference to 
the parent Interrupt handler for an I/O function and a 

30 SetParentlntenuptHandlerReferenceO writes the reference to the parent 
Intermpt handler for an I/O function to a private attrbiute. 
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A GetLowerinterruptSocketQ method reads the lowest Interrupt socket 
numt)er which can be assigned to the I/O function and a 
SetLowerlnterruptSocket method writes the lowest Interrupt socket number 
which can be assigned to the I/O function. Similarly, a 
GetUpperlnterruptSocket method reads the highest Interrupt socket number 
can be assigned to an I/O function and a SetUpperlnten\jptSocket() method 
writes the highest Interrupt socket number can be assigned to an I/O function. 

An IsSharableO method returns a first value (e.g. boolean TRUE) if the 
socket can be shared and a second different value (e.g. boolean FALSE) if 
the socket cannot be shared. A SetSharability() method writes the sharability 
of the socket into a private attribute. A GetlnterruptUsageMode() method 
reads the usage mode for the intenupt socket used by an I/O functbn and a 
SetlntenruptUsageModeO writes the usage mode for the intenupt socket used 
by an I/O function. 

The TDMAConstraint dass 1614 encapsulates Information about a 
DMA channel used by an indivklual I/O functton. The TDMAConstraint dass 
1614 is a monomorphk: dass and Is nested inside 
TPossiblelOResourceAssignmentdass 1608. The TDMAConstraint dass 
1614 is normally not subdassed by devetopers. 

The TDMAConstraint dass 1614 indudes a plurality of nrtember 
fiincttons induding a GetChannelReference() method reads a reference to the ' 
DMA channel handle from a private attribute and a SetChannelReference() 
method writes the reference to the DMA channel handle to the private 
attribute. 

An IsSharableO method r^ms a first value (e.g. boolean TRUE) if the 
DMA channel used by the I/O function can be shared by other I/O functions 
and a SetSharability() method writes the sharability for the I/O function. A 
GetDMAUsageModeO reads the usage mode for the DMA channel used by 
the I/O function and a SetDMAUsageMode() writes the usage mode for the 
DMA channel used by the I/O fiinctk>n. 

6. Manual Module Framework Classes 
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Figures 17, 18A. 18B and 19 illustrate a set of classes which form a 
manual module framework. The manual module framework is provided from 
a set of dasses that represent the general behavior of manually-configured 
expansbn cards and the motherboard of the computer system. The classes 
of the manual module framework insure, inter alia, a persistent configuration 
of both manually-configured expansion cards and the motherboard from one 
boot operation to the next. It is this framework which is responsible for 
retrieving the configuration information from the hardware configuration 
database during boot operation. 

In general overview, during boot operations, the manual module 
framework classes aid in instantiating configuration recorder objects for the 
motherboard and any manual expansion cards Installed in the computer 
system. More specifically, the booting system instantiates a 
TManualRecorderRegistry object which instantiates the configuration recorder 
objects for the mothertx)ard and the manual expansion cards. 

The manual module framework also includes classes that aid in 
installing new expanston cards with a computer viewer object as explained 
above. The manual nrxxiule frameworic provides a TManuallOCard object 
which communicates with the resource conflict resoiver object and the 
configuration option retriever objects that retrieve the resource requirements 
for the mothertx>ard and manual expansfon cards from a configuration optfon 
database. 

Referring now to Figure 17, the nnanual module framework includes a 
TManualConfigurationRecorder class 1700 having a CreateModuleMaker() 
method, an lsRoot() method, a NeedsRecognition() method and an 
InitiateNestedRecognizerO method. A TMotherit)oardConfiguratk>nRecorder 
dass 1702 inherits from the TManualConfigurationRecorder dass 1700 (i.e. 
the TMotheri3oardConfigurationRecorder dass is a subdass of the 
TManualConfigurationRecorder dass) and thus indudes each of the member 
functions of the TmanualConfigurationRecorder class 1700. The 
TMotherit>oardConfigurationRecorder class 1702 also includes a 
GetExpansionBusRecognizersO method, a DolnitiateNestedRecognizers() 
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method, a RegisterPossibleAssignments() method and a 
ProduceConflictFreeAssignmentsO method. 

The TManualConfigurationRecorder class 180 creates a configuration 
recorder which will record the conflict-free resource assignments generated 
5 by the resource conflict resolver object in the hardware configuration 
database. A configuration recorder object for a manually configurable 
component is responsible for creating a hardware module object for the 
component, which object encapsulates the hardware description of the 
component The recorder object also creates a hardware Identifier object for 

10 each of the connectors on the component and adds the hardware identifier 
objects to the hardware module. 

A TManualConfigurationRecorder object is instantiated finom the 
TManualConfigurationRecorder class 1700 and is used to construct the 
configuration recorder object for a manual component such as a manual ISA 

15 card or a local bus card. The TManualConfigurationRecorder class 1700 is 
an abstract base class and must be subclassed to allow a particular 
configuration recorder object for an individual manually configurable I/O 
expansion card to be instantiated therefrom. A 

TManualConfigurationRecorder object for a specific card is instantiated by the 
20 computer viewer during the installation of the card. A recorder object for a 
manual card that needs to invoke nested recognizers during a system boot 
operation (such as a SCSI bus) is registered witti a ManualRecorderRegistry 
object that is persistent. During a boot operation, the 
ManualRecorderRegistry object instantiates the recorder for the card and 
25 invokes the lnrtiateNestedRecognizers() method of the recorder object in 
order to instantiate nested recognizers as required by the card. 

A derived dass of TManualConfigurationRecorder class 1700 must 
implement the CreateModuleMaker() mettiod. The CreateModuleMaker() 
method is invoked by the computer viewer during installation and creates a 
30 HardwareModuleMaker object that represents the card, creates a 

THardwarelnterfaceldentifier object to represent each connector on the card 
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and adds them to the THardwareModuieMaker object for the card created 
above. 

An identifier for the edge connector 
(TUniqueNonActivatableHardwarelnterfaceldentifier) is passed in by the 
5 computer viewer object during construction of the object and the recorder 
object adds the identifier to the card module. The parent for the edge is not 
set for a Manual I/O card. For connectors representing an activatable 
function, the corresponding identifiers must be created by subclassing from a 
TIOFunctionHardwarelnterfaceldentifier class. A developer writing a sub- 

10 class of the TIOFunctionHardwarelnterfaceldentrfier class need not set the 
"other End" or "connection kind" attiibutes of the HardwareModuleMaker 
object, since these attributes are set by the computer viewer object. The 
developer should not set tiie "this end" attribute of ttie maker, because it 
defaults to the default connector of the nrKxiule (typically edge). 

15 An IsRootO method returns FALSE by default and retums TRUE only 

for the motherit)oard configuration recorder object. The lsRoot() method is 
called by a manual recorder registry object to check if the recorder object is 
for the mothert>oard. 

A NeedsRecognitionO method retums FALSE by default and can be 

20 ovem'dden to retum TRUE if the subclass needs to invoke secondary 

recognizers. This method ts called by the manual recorder regtetry object to 
check if the card needs to invoke any secondary recognizer objects during a 
boot operation. 

An InitiateNestedRecognizersO method instantiates any secondary 
25 recognizer objects required by the card. By default, tiiis method does nothing. 
Developers should ovenide this method if the card needs to invoke a 
secondary recognizer object during a boot operation. The configuration 
recorder object stores the function kientifier for the fonction that needs 
recognition. If a subclass ovem'des this method, its CreateModuleMaker() 
30 method should save (in object state) any identifiers required by the 
InitiateNestedRecognizersO mettiod. 
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The TMotherboardConfigurationRecorder Class 1702 is used to 
construct a configuration recorder for the nrK)therboard of the computer 
system. The TMothert)oardConfigurationRecorder dass 1702 is an abstract 
base dass and must be subdassed to represent the configuration recorder 
object for a specific motherboard. The 

TMotherboardConfigurationRecorder dass 182 is responsible for creating a 
hardware module object for the motherboard, creating hardware identifier 
objects for each connector other than expansion bus slots on the 
mothertx)ard, adding the identifier objects created above to the motherboard 
module, instantiating recognizer objects for each expansion bus (such as ISA, 
PCI, etc.) on the motherboard and instantiating nested recognizer objects 
(such as SCSI recognizer objects) required by the motherboard. 

The TMotherboardConfigurationRecorder dass 1702 is instantiated by 
a computer viewer object during installation of the motherboard. The 
mothertx>ard recorder object is persistently registered with the 
ManualRecorderRegtstry ob^ t>ecause it always incorporates buses that 
require nested recognizers. During a system boot operation, the 
ManualRecorderRegistry object instantiates the mothertx)ard recorder object 
and invokes the InitiateNestedRecognizersO method of the motherboard 
recorder object This latter method then instantiates expansion bus and 
nested device txjs recognizer objects as required. 

The TMotherboardConfigurationRecorder dass 1702 also indudes a 
plurality of member functions induding an lsRoot() method which is called by 
the manual recorder registry object to check if the recorder object is for the 
mothertx>ard. If the recorder object is for the mothert)oard the lsRoot() 
method returns a first predetermined value (e.g. a tx>olean TRUE value). 

A NeedsRecognitionO method is called by the manual recorder registry 
object to determine if the niothertx)ard requires any secondary recognizer 
objects to be invoked during a boot operation. If secondary recognizer 
objects are required then the NeedsRecognitionO method retums a first 
predetermined value (e.g. a boolean TRUE value). 
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An InitiateNestedRecognizersO method instantiates the recognizers for 
all expansion buses (such as ISA, PCI, etc.) and device buses (such as 
SCSI) on the motherboard. The InitiateNestedRecognizers method also 
Invokes the GetExpansionBusRecognizers() method to determine the 
recognizer objects for the expansion buses on the motherboard, iterates over 
the collection of TIOCardRecognizer objects returned by the previous step 
and invokes appropriate methods of each recognizer object to register the 
resource requirements for the functions on cards residing on each expansbn 
bus with the resource conflict resolver object. It also invokes the appropriate 
method of the resource conflict resolver object to produce conflict-free 
resource assignments for each function on the motherboard and expansion 
cards, invokes the appropriate methods of each auto-configurable recognizer 
object to instantiate configuration recorder objects for the expansion cards 
and calls the DolnitiateNestedRecognizers() method to instantiate secondary 
recognizer objects on the motherboard, if required. 

A RegisterPossibleAssignnmentsO method is not ovem'dden by 
developers and registers the resource requirements, such as possible 
resource assignments and constraints, in resource assignments for the 
mothertx)ard functions with the resource conflict resolver object. 

A DolnitiateNestedRecognizersO method, by default, does nothing and 
devetopers can override this method to instantiate a secondary recognizer 
object (such as SCSI recognizer object) on the mothertx>ard, if required. The 
configuration recorder object stores the identifier for the function that needs 
recognitbn. 

A GetExpansionBusRecognizersO method must be implemented by 
developers to return a collection of recognizer objects for the expansion 
buses on the motheritx>ard. 

The TManualRecorderRegistry class 1704 includes an 
InitiateAIIRecognizersO method and a RegisterForBootTimelnitiation() 
method. A TManualRecorderRegistryHandle represents the persistent 
registry of configuration recorders for manually-configured I/O expansion 
cards that require nested recognizers to be instantiated during boot. If a card 
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requires a nested recognizer object to be instantiated during a system boot 
operation then during installation of the card, the recorder object for that card 
is added to the recorder registry database. During a system boot operation, 
the booting system invokes the InitiateAIIRecognizersO method of the 
5 recorder registry database. The recorder registry will then iterate across all 
recorder objects registered therein, starting first with the motherboard 
recorder, calling an lnitiateNestedRecognizer() method on each registered 
TManualConfigurationRecorder object. 

The TManualRecorderRegistry object is self garit>age-collecting. It 

10 performs garbage collection first, each time it is requested to instantiate all of 
its recorders. Garbage collection is handled by obtaining a collection of all of 
the THardwareModuleHandle objects in the hardware configuration database, 
iterating across all of its TManualConfigurationRecorder objects and verifying 
that for each recorder object, there still exists a hardware module in the 

15 hardware configuration database. If not, then the corresponding 

TManualConfigurationRecorder object is automatically deleted from the 
recorder registry. 

The TManualRecorderRegistry dass 1704 is a monomorphic class 
which is not normally subclassed by developers. In addition to the above- 

20 described methods, dass 1704 also indudes a 

RegisterForBootTtmelnitiationO method which registers with the booting 
system that the recorder registry exists so that the InitiateAIIRecognizersO 
method will be called during the booting process. 

Referring now to Figure 18A, the manual module finamework further 

25 indudes several configuration option retriever dasses. These dasses indude 
the TMotherboardConfigurationOptionRetriever dass 1802 and a 
TManualConfigurationOptionRetriever dass 1804, each of which are a 
subdass of, and thus inherit from, a TConfigurattonOptionRetalever dass 
1800 discussed above in conjunction with Figure 8. The 

30 TMothert)oardConfigurationOptionRetriever class 1 802 is a monomorphic 
dass which is not normally subdassed by developers. 
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The TMotherboardConfigurationOptionRetriever class 1 802 
implements the protocols for retrieving resource requirements such as 
possible resource assignments, constraints in resource assignments and 
default resource assignments con^sponding to the factory setting of the 
motherboard, from persistent configuration option files, such as configuration 
files of EISA and ISA expansion cards. These default configurations can be 
added to the configuration option database with the assistance of the 
computer viewer or provided by card manufacturers. 

The TMotherboardCk>nfigurationOptionRetriever class 1802 includes a 
method, GetVendorlnformation(), which returns vendor specific infbnmation 
for an expansion card and a method, GetCardType(), which retums the type 
for the expansion card. The TMotherboardConfigurationOptionRetriever 
class 1802 also includes a method, GetFunctjonCount(), which retums the 
number of fijnctions on an expansion card and a method, 
GetFunctionlnformationO, which retums the function information for an 
individual function on an expansion card. 

A GetPossibleAssignmentsO method of class 1802 retrieves and 
retums the choices in resource assignments for an individual function on an 
expansion card and a GetDefaultAssignnnentO method of class 190 retums 
the default resource assignment for an individual fonction corresponding to 
the factory setting of the card. 

Refening momentarily to Figure 18B, a TManualSlotldentifier dass 
1808 represents the hardware identifier for the slots of a manual bus such as 
ISA, VESA, etc. and is a sub-class of a THardwarelnterfoceldentifier class 
1 806. A ManuaiSlotldentifier object instantiated from dass 1 808 
encapsulates a SlotNumber which is used as a key to retrieve the 
configuration infonmation from the configuration option database. 

Refem'ng again to Figure 18A, the 
TManualConfigurationOptionRetriever dass 1804 has instantiated tiierefirom 
objects which retrieve the resource requirements and other configuration 
information for manual expansion cards from pensistent configuration files. 
The TManualConfigurationOptionRetaiever dass 1804 implements the 
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protocols for retrieving resource requirement, such as possible resource 
assignments, constraints in resource assignments and default resource 
assignment corresponding to the factory setting of a manually-configured I/O 
expansion card, from persistent configuration files (such as configuration files 
5 of EISA and ISA type expansion buses arid cards). The 

TManualConfigurationOptionRetriever class 1804 is a monomorphic dass 
which is not normally subclassed by developers. 

The TManualConfigurationOptionRetriever class 1804 includes a 
method, GetFunctionCount(), which retums the number of functions on an 

10 expansion card and another method, GetFunctionlnformation(), which retums 
the function information for an individual function on the expansion canJ. 

Class 1804 also includes a method. GetPossibleAssignments(), which 
retums the choices in resource assignments for an individual function on the 
card and another method. GetDefaultAssignment(), which retums a default 

15 resource assignment for an individual function corresponding to the factory 
setting of the expansion card. 

Class 1804 further includes a method, GetVendorinfonnation(), which 
retums vendor specific information for an expansion card and a further 
method, GetCardType(), which retums the type of the card. 

20 Referring now to Figure 19, in general overview, the manual module 

frameworic also includes TManuallOCard dass 1900. Objects instantiated 
from the TManuallOCard dass 1900 represent the behavior of manually- 
configured expansion cards such as manual ISA expansion cards, manual 
Local bus expansion cards and the motherboard. The TManuallOCard dass 

25 1 900 is associated with a TManuiallOFunctionResources dass 1 902. 

A ManuallOFunctionResources object instantiated from dass 1902 
encapsulates the resource requirements such as possible resource 
assignments, resource assignment constraints and a default resource 
assignment for an individual function on a manual I/O card or nrK)thert)oard. A 

30 ManuallOFunctionResources object also encapsulates the 
TManuallOFunctionlnformation for the function. The 
TManuallOFunctionResources dass 1900 indudes a private attribute which is 
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a deque of objects instantiated from the TPossibielOResourceAssignment 
class 1 906 and a private attribute which an object instantiated from a 
TManuallOFuncttonlnfonmation dass 1908. 

The TPossibielOResourceAssignment class 1906 is used to create 
5 objects which encapsulate possible resource assignment sets for a particular 
function, defeult assignment sets and constraint sets for the function as 
described above. The TManuallOFunctionlnformation class 1908 
encapsulates infonnation such as function type for an I/O function on a 
manual expansion card or motherboard. 

10 The TManuallOCard class 1900 is a monomorphic class which is not 

normally subclassed by developers. A ManuallOCard object instantiated from 
this class encapsulates information, such as generic card and vendor specific 
information of a manually-configured card such as ISA card, a Local bus card 
and a mothertx>ard. ManuallOCard objects also include a private deque of 

15 ManuallOFunctionResource objects, one for each function on the card. As 
discussed above, during installation of a Manual I/O card or a motheritx>ard, a 
computer viewer ot>ject uses a ManuallOCard object to communicate with 
the resource conflict resolver. 

Other responsibilities of the ManuallOCard object are: (1) registration 

20 of resource requirements such as the possible resource assignments and 
constraints in resource assignments for the functions on the card with the 
resource conflict resoiver object; (2) invocation of an appropriate method of 
the resource conflict resoh/er object to produce conflict-free resource 
assignments for individual functions on the card t>eing installed; (3) 

25 attachment of the ManuallOCard object with the default connector object on 
the card; and (4) disabling and enabling individual functions on the card. 

The TManuallOCard dass 1900 includes a plurality of member 
functions including a method, RegisterPossibleAssignments(), for registering 
the possible resource assignments for all functions on a manual I/O card or a 

30 motherboard with the resource conflict resolver object. Possible resource 
assignments for each function on the expansion card must be set up by 
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instantiating the appropriate PossibielOResourceAssignment objects before 
call to RegisterPossibleAssignments(). 

The class 1900 also includes another method. 
SetFunctionAssignmentConstraintsO, for registering constraints in a resource 
5 assignment for an I/O function on a card with the resource conflict resolver 
object and a further method, RemoveFunctionAssignmentConstraints() for 
removing resource assignment constraints associated with an I/O function 
that does not have a resource assignment. The method for registering 
constraints in a resource assignment for an I/O function is used by clients to 

10 force the resource assignment for an I/O function to a specific value. The 
constraints must not be in conflict with the possible resource assignments for 
the card. If there is any conflict in the constraints, this method throws an 
exception. Each of the aforementioned methods throw an exception if the 
card or the fonction is not registered with the resource conflict resolver 

15 object. 

Class 1900 also includes a method, 
ProduceConfllctFreeAsslgnmentsO, which produces a conflict-free resource 
assignment for I/O foncttons on the motherit>oard and expansion cards in the 
system for a specified boot period. The boot period indicates to the resource 

20 conflict resolver object to produce the resource assignment for this boot 
operation (kThlsBoot) or a next boot operation (kNextBoot). This method 
generates lOFunctionResource/Vssignment objects for all I/O functions 
currently without resource assignments. If there are any resource conflicts, 
this method creates a lOResourceConflict object and throws an exception if 

25 any resource conflicts are encountered while producing the resource 
assignment. 

Class 1900 forther includes a method, GetCardResourceUsage(), 
which is called to get conflict-free resource assignments for all I/O fonctions 
on a card identified by the SiotlD. The conflict-free resource assignments are 
30 created by a prior call to the ProduceConflictFreeAssignments() method. The 
GetCardResourcellsageO method throws an exception if the card is not 
registered with the resource conflict resolver object 
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Class 1 900 also includes another method, 
RemoveCardResourceUsageO which is called to remove all resource 
assignments (encapsulated in lOCardResourceUsage object) for a particular 
expansion card. This method is typically called when an expansion card is 
removed from the computer system and the method generates an exception if 
the resources are In use. 

A GetFunctionAsslgnmentO method of class 1900 retums a conflict- 
free resource assignment for an I/O function. A unique 
Hardwarelnterfaceldentifier for the I/O function is passed in as a key to obtain 
the resource assignment. The configuration recorder object for a card creates 
the function identifier by subclassing from the 

TIOFunctionHardwarelnterfaceldentifier class. This method retums the 
resource assignment for a card, even if the hardware is not physically 
installed in the computer system and throws an exception if the resource 
assignment is not created, or if there is any conflict in creating a resource 
assignment for this I/O function. This method also throws exception If the 
function Is not registered with the resource conflict resolver object This 
method is called by the recognizers and control panels only. 

A GetResourceConflictsO method of dass 1 900 retums the conflicts in 
resource assignment for an I/O function. A unique Hardwarelnterfaceldentifier 
for the I/O function is passed in as a Icey to obtain the resource conflicts: This 
method throws exception if the funclton is not registered with the resource 
conflict resolver object This method is only called by the recognizer objects 
and control panel objects. 

A RemoveFunctionAssignmentO method of dass 1900 is called to 
remove the resource assignment (encapsulated in a 
lOFunctionResourceAssignment object) for an I/O function. This method is 
called when a I/O function is removed from the computer system. The caller 
asserts that the resources are not being responded to by the corresponding 
hardware. This method generates an exception if the resources are in use or 
if the function is not registered with the resource conflict resolver object. 
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A RemoveFunctionResourceUsageO method of class 1900 is called to 
remove the resource usage(encapsulated in a TIOFunctionResourceUsage 
object) associated with an I/O function. The 

RemoveFunctionResourceUsageO method is called when an I/O function is 
5 removed from the system. The caller asserts that the resources are not being 
responded to by the conresponding hardware. This method generates an 
exception if the resources are in use. This method also throws exception if the 
function is not registered with the resolver. 

An AttachO method attaches the ManuallOCard object with the 

10 hardware interface identifier for a connector on the card typically the default 
(edge) connector. A DisableFunctionQ method is called to disable an existing 
function on a manual card or a motherboard. The caller asserts that the 
function is electrically isolated. An EnableFunction() method, on the other 
hand, is called to enable a previously disabled function on a manual card or a 

15 motherboard. 

A GetTypeO method returns the type of the manually-configured card 
and a SetType() method writes the card type to a private attribute. A 
GetVendorinfomiationO method retums the vendor information and a 
SetVendorinfomnationQ method writes the vendor information to a private 

20 attribute. 

A GetFuncttonResourcesO method reads the 
ManuallOFunctionResources objects for the functions on the card and a 
SetFunctionResourcesO writes the ManuallOFunctbnResources objects into 
an internal deque for the functions on the card. 

25 The TManuallOFunctionResources dass 1902 is a nx)nomorphic class 

which is not normally subclassed by developers. The 
TManuallOFunctionResources dass 1902 indudes a plurality of member 
functions induding a GetPossibleAssignments() method which reads the 
possible resource assignments for the function and a 

30 SetPossibleAssignmentsO method which writes the possible resource 
assignments for the function. 



120 



wo 99/39268 



PCTAJS99/01740 



A GetDefauitAssignmentO method reads the default resource 
assignment for the function and a SetDefaultAssignment() method writes the 
default resource assignment for the function. The default resource 
assignment corresponds to the fectory setting for the function on the card. 
5 A GetAsslgnmentConstraintO method reads the constraints In resource 

assignments for the function and a SetAssignmentConstraint() writes the 
constraints in resource assignments for the function. 

The TManuallOFunctionResources class 1902 also includes a 
GetFunctionlnfomiationO method and a SetFunctionlnfonnationO method. 
10 The GetFunctionlnformationO method reads the 

TManuallOFunctionlnfomiationO for the function and the 
SetFunctionlnformationO writes the TManuallOFunctionlnformation for the 
function. 

The TManuallOFunctionResources class 1902 also includes a 
15 GelFunctionStatusO method and a SetFunctionStatus() method. The 

GetFunctionStatusO nrtethod retums a first enumerated value (kDisabled) if 
the function on the card is disabled. The SetFunctionStatus() method writes 
the status for the function and when an I/O function is disabled, the resource 
conflict resolver object will not produce a resource assignment for that I/O 
20 function and those resources may be allocated to other I/O functions in the 
system. If the disabled I/O fururtion is electrically present in the system and 
the resources used by the disabled I/O function are assigned to other I/O 
functions, there may be problems. The user should ensure that the I/O 
function is electrically isolated before it is disabled. 
25 The TManuallOFunctionlnfomiation dass 1908 is a mononmrphic 

dass which is not normally subdassed by developers and indudes a plurality 
of member functions induding a GetFunctionType() method reads a function 
type that indicates the I/O operation represented by the function and a 
SetFunctionTypeO sets the function type. 

30 

ISA Bus Framework classes 
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Figures 20, 21 A. 21 B and 22 illustrate a set of classes which form an 
ISA bus framework. The ISA bus framework indudes a plurality of classes 
which are used in dynamic tx)oting of operating system device drivers for 
devices installed on the motherboard and expansion cards installed in an ISA 
5 based machine. 

Refem'ng now to Figure 20, an illustrative ISA framework includes a 
TMCACardRecognizer class 2002, a TElSACardRecognizer class 2006, a 
TPCICardRecognizer class 2008, a TMotherboardRecognizer class 2010, a 
TPCMCIACardREcognizer class 2014, a TPIugNPIaylSACardRecognizer 

10 class 201 2 and a TManuallOCardRecognizer class 201 6 and 

As shown in Figure 20, the TMotherboardRecognizer class 2010 is 
derived from a TIOCardRecognizer class 2004 and represents the recognizer 
for the mother board of the system. A MotherboardRecognizer object is 
instantiated from the TMotherboardRecognizer class 2010 and detenmines 

15 the functions on the mothertx>ard and registers the possible resource 

assignments of the functions with the resource conflict resoh^er object The 
MotherboardRecognizer object is also responsit)le for instantiating a 
configuration recorder object for the mothert)oard of the computer 

The TMothert)oardRecognizer class 2010 includes a plurality of 

20 member functions including DoBoot() method and a method 

(RegisterPossibleAssignmentsO) whk:h is called to register the possible 
resource assignments for each functton on the mothert)oard with the resource 
conflict resolver object. The possible resource assignments for the 
motherboard functions are retrieved from the configuration option database. 

25 The TMothertx>ardRecognizer class 2010 also includes a method 

(InstantiateRecordersO) which is called to instantiate an appropriate 
configuration recorder object for the mothert)oard. 

The TManuallOCardRecognizer dass 2016 has instantiated therefrom 
recognizer objects for all manual I/O cards such as traditional ISA and Local 

30 bus cards in the system. The recognizer objects determine which manual I/O 
cards are in the computer system and register their possible resource 
assignments with the resource conflict resolver object. It is also responsible 



122 



wo 99/39268 



PCT/US99/01740 



for instantiating an appropriate configuration recorder object for each manual 
I/O card in the system. 

As can be seen in Figure 20, the TManuailOCardRecogntzer class 
2016 is derived from a TIOCardRecognizer dass 100 described above in 
conjunction with Figure 7. ManuallOCardRecognizer objects are instantiated 
by booting system in accordance with a set of recognizers identified in a 
TIOCardRecognizerSet object (instantiated from the TIOCardRecognizerSet 
class 2000) and registers the possible resource assignments for the 
manually-configured I/O cards with the resource conflict resolver object. The 
TManuallOCardRecognizer objects are also responsible for instantiating the 
configuration recorder objects for the manual I/O cards in the computer and 
can be destroyed after invoking a DoBoot() method which is a member 
function of the TManuallOCardRecognizer class 2016. 

The TManuallOCardRecognizer class 2016 includes a plurality of 
member functions including a method (RegisterPossibleAssignments()) which 
registers the possible resource assignrhents for the functions on a ManuaM/O 
card such as traditional ISA or Local bus card with the resource conflict 
resolver object. Such possible resource assignments for the functions are 
retrieved from the configuration option database as previously described. 

The TManuallOCardRecognizer dass 2016 also indudes a method 
(InstantiateRecordersQ) which Is called to determine which manually- 
configured expansion cards are in a system and to instantiate the appnspriate 
configuration recorder object for each of the manuallyKX>nfigured expansion 
cards. The manually-configured cards are determined by searching the 
hardware configuration datatiase as previously described. 

The TPIugNPIaylSACardRecognizer class 2012 represents recognizer 
objects for all Rug & Play ISA cards in the system. In a similar manner, the 
TMCACardRecognizer class 2002, the TEISACARDRECOGNIZER dass 
2006 and the TPCMCIACardRecognizer dass 2014 are used to instantiate 
object which represent MCA cards, EISA cards and PCMCIA cards. Objects 
instantiated from the TPIugNPIaylSACardRecognizer dass 2012, the 
TMCACardRecognizer dass 2002, the TEISACARDRECOGNIZER dass 
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2006 and the TPCMCIACardRecbgnizer class 2014 identify the Plug & Play 
ISA cards, MCA cards, EISA cards and PCMCIA cards In the computer 
system and register their possible resource assignments with the resource 
conflict resolver object. Objects 2002, 2006 2008. 2012 and 2014 are also 
5 responsible for configuring each ISA card with conflict-free resource 
assignments and for instantiating the appropriate configuration recorder 
object for each ISA card in the computer system. 

Classes 2002, 2006, 2008, 2012 and 2014 are derived from the 
TIOCardRecognizer class 2004 and represent the recognizers for all ISA 

10 expansion cards in the system. Object are instantiated from these classes by 
the booting system using information in the lOCardRecognizerSet object and 
register the possible resource assignments for the ISA cards with the 
resource conflict resolver. The corresponding recognizer objects are also 
responsible for instantiating configuration recorder objects for all the ISA 

15 cards in the computer system and for configuring the ISA cards with conflict- 
free resource assignments computed by the resource conflict resolver object. 
The recognizer objects can be destroyed after invoking a DoBoot() mettiod 
which is a member function of the recognizer classes 2002, 2006, 2008, 2012 
and 2104. 

20 The TPIugNPlay ISACardRecognizer class 201 2. the 

TMCACardREcognizer class 2002 and the TEISACARDRECOGNIZER class 
2006 include a plurality of member functions including a method 
(RegisterPossibleAssignmentsO) which registers the possible resource 
assignments for a Plug & Play ISA card witti the resource conflict resolver 

25 object The possible resource assignments are retrieved from the cardsJ 
Classes 2002, 2006, 2008, 2102 and 2104 also include a method 
(InstantiateRecordersO) which is called to recognize the corresponding ISA 
cards in a system and to instantiate the appropriate configuration recorder 
objects for each ISA card in the system. Each ISA card includes a read only 

30 memory in which is stored an identification code which uniquely identifies the 
card as being an ISA card. Each ISA card can thus be recognized by 
retrieving from the cards the unique card identification codes which are stored 
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in the read only memory of the card. The cards are also capable of being 
programmed with resource assignments and this capability can be used to 
configure the ISA cards with the conflict-free resource assignments computed 
by the resoun::e conflict resoiver object. 
5 The RegisterPossibieAssignmentsO method and the 

InstantiateRecordersO methods have the following form: 

virtual void RegisterPossibleAssignments (const 
TIOConflictResolverHandle& resoiver); 

10 

virtual void InstantiateRecorders (const TtOConflictResolverHandle& 

resoiver, 

const THardwareModuleMaker& parentDevice, 
const short slotlndex, 
1 5 const short slotCount, 

const THarclwarelnterfaceldentifer& 

parentlnterface, 
const TlnterruptHandlerReference& 

parentHandler); 

20 

The configuration information of a card can be viewed by double- 
didcing a card icon which is displayed with a computer viewer object. When 
the user double-dicks on the card icon, the configuration information for the 
card is retrieved from a THardwarelnterfaceldentifier object for the slot into 

25 which the card is plugged. For nrK)therboards, the configuration information is 
retrieved from a special THardwarelnterfaceldentifier object created for 
motherboard. The configuration information for the card is stored in the 
THardwarelnterfaceldentifier object for the slot by the corresponding 
recognizer object. For manual I/O cards, the configuration infonmation is also 

30 stored in the THardwarelnterfaceldentifier object by the card viewer object. 

The resource assignments for manual I/O cards can be changed using 
the card viewer object. Any change in resource allocation is checked for any 
conflicts by the TManuallOCard object in the same manner as for a newly 
added card. The ISA bus framework does not support any mechanism that 
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allows a user to manually change the configuration of auto-configurable 
cards. 

If the appropriate configuration recorder object for a card is not found, 
the bus object spawns a new thread that waits for the card's configuration 
5 recorder object to become available in the computer system. This thread will 
be alive even after the bus object gets destroyed. When the Configuration 
Recorder object for the card is available, it is instantiated. It is assumed that 
the address space the thread lives in will not go away until system shut down. 
Referring now to Figures 21 B and 21 B, the ISA framewori^ further 

10 includes a set of configuration recorder objects. This set includes a plurality 
of base classes from which subclasses representing specific boards are 
derived. For example, a TManuallOCardConfigurationRecorder base class 
2100 has a derived subclass for a particular card, denoted as a 
TSampleManuallOCardConfigurationRecorder class 2104, from which a 

15 configuration recorder object for a particular manual I/O card (e.g. a traditional 
ISA card or a manually-configured local bus card) is instantiated. The 
configuration recorder object is responsible for registering the manual I/O 
card and recording its configuration information in the hardware configuration 
database. 

20 A ManuallOCardConfigurationRecorder object is the configuration 

access manager for a manual I/O card, such as an ISA card or a local bus 
card, in a computer system having an ISA architecture. Consequently, the 
ManuallOCardConfigurationRecorder object includes methods which deal 
directly with the hardware on the card. 

25 The TSampieManuallOCardConfigurationRecorder dass 2104 is 

instantiated during a system boot operation by a TManuallOCardRecognizer 
object. This class is also instantiated whenever the user adds a new manual 
I/O card with the help of the computer viewer object as described above. A 
SampieManuallOCardConfigurationRecorder object can be destroyed after 

30 invoking a DoBoot() method which is a pure virtual member function of the 
TManuallOCardConfigurationRecorder class 2100. Consequently, each dass 
which is derived from the TManuallOCardConfigurationRecorder class 2100 
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nuist implement the DoBoot() method: The OoBoot() method is invoiced by a 

ManuallOCardRecognizer object in order to instantiate a configuration 

recorder object for a nnanual I/O card in an ISA machine. This method is also 

invoked by the Card Viewer in order to instantiate the Configuration Recorder 

5 for a new Manual I/O card. The DoBoot() method of dass 21 00 has the fomi: 

virtual void DoBoot (const TManuaiiOCard& card, 

const TCollection<TManuailOFunctionResources>& 

funcs, 

const THaFdwarelntefaceldentlfler& slotID) = 0 

10 

This method (1) creates a THardwareModuleMaker object that 
represents the I/O card; (2) creates a THardwarelnterfaceldentifier object to 
represent each connector on the card and stores the resources associated 
with the connector (such as parent TlntemjptHandler, 

15 InterruptSocketNumber, etc.) in that object; (3) adds the 

THardwarelnterfaceldentifier objects created above to the parent 
THardwareModuleMaker object passed in; and (4) registers the card 
(THardwareModuleMaker) with computer hardware configuration database. 
The mothertx>ard configuratnn recorder classes 21 08 and 21 12 are 

20 constructed and behave in an analogous fashion to the manual lO cards 
configuration recorder classes 2100 and 2104, respectively. 

The framework includes other classes which are used to instantiate 
configuratbn recorder objects for other ISA cards, such as Plug N Play cards. 
PCI cards, PCMCIA cards, MCA cards and EISA cards. For example, a 

25 TRugNPIaylSACardConfigurationRecoreler dass 21 02 is an abstract base 
dass and must be subclassed before a configuration recorder object for an 
indivKlual Plug & Play ISA card can be instantiated therefrom. In F^ure 21A. 
such a subdass is the TSamplePlugNPIaylSACardConfigurafionRecorder 
dass 2106 which would be tailored for a particular card. A 

30 PlugNPIaylSACardConfigurationRecorder objed instantiated from a 
TSamplePlugNPIaylSACardConfigurationRecorder dass 2106 is the 
configuration access manager for a Plug & Play ISA card. The 
TSamplePlugNPIaylSACardConfigurationRecorder dass is instantiated during 
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a boot operation by a corresponding PlugNPIayiSACardRecognizer object for 
the card. A SamplePlugNPIaylSACardConfigurationRecorder object can be 
destroyed after Invoking Its DoBoot() method which is a member function of 
the TPIugNPIaylSACardConfigurationRecorder dass 2102. 
5 Each dass derived from the 

TPIugNPIaylSACardConfigurationRecorder dass 21 02 must Implement the 
DoBootO method. The DoBoot() method is invoked by a 
TPIugNPIaylSACardRecognizer object In order to Instantiate the configuration 
recorder object for a Plug & Play ISA card In the system. The DoBoot() 
10 method of class 21 02: (1 ) creates a THardwareModuleMaker object that 
represents the Plug & Play ISA card; (2) creates a 

THardwarelnterfaceldentlfier object to represent each connector on the card 
and stores the resources associated with the connector (such as parent 
TlntenuptHandler, IntenruptSocketNumber, etc.) in that object; (3) adds the 

15 THardwarelnterfaceldentlfier objects created above to the parent 
ThardwareModuleMaker object passed in; and (4) registers the card 
(THardwareModuleMaker) with the computer hardware configuration 
database. The remaining dasses 2110, 2114; 2116, 2120; 2118, 2122 and 
2124, 2126 function In an analogous manner. 

20 Refemng now to Figure 22, the ISA bus framework also Indudes a 

TManuallOCard dass 2200 from whtdi a TManuallOCard object Is 
Instantiated. A TManuallOCard object represents the behavior of a manually- 
configured I/O component such as an ISA card, a local bus card or a system 
board device in an ISA based machine. This object encapsulates the card's 

25 infonmatk>n, such as generic card and vendor specific informatk>n. This 
objed can be Instantiated by a TManuallOCardRecognizer object, a 
TMothertioardRecognlzer object or a card viewer object and passed to the 
corresponding configuration recorder objects. 

The TManuallOCard dass 2200 Indudes a plurality of member 

30 functtons induding a DetectResourceConflid() method which checks the 
proposed resource assignment for cards being added to the system to make 
sure that there is no conflict in the resource allocation of the card. If there is 
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no conflict, the method returns a first enumerated value (kNoConflict). If there 
Is a resource conflict and If the resource conflict can be resolved during a next 
t)oot operation the method returns a second different value 
(kNoConflictAflerBoot). If there is conflict and it can not be resolved 

5 automatically, the method returns a third value (kConflict). The method also 
makes a copy of a lOResourceAssignments object passed in during 
instantiation and returns information about the conflicting functions for the 
proposed resource assignment in a conflicts argument of the method. The 
proposed resource assignments are compared with the existing resource 

10 assignments to detect a conflict and proposed resource assignments, 
obviously, must not themselves conflict with the possible resource 
assignments. This method has the form: 

virtual ConflictResult DetectResourceConflict (const 
15 TIOCardResourceUsage& proposal, 

TCoilection<TIOResourceConflict> conflicts); 

Anotiier method, GetPossibleConflictFreeAssignmentsQ, is called to 
obtain infomnation about conflict-free resource assignments cunrentiy 

20 available and conflict-free resource assignments that will be available after a 
ret)oot operation is performed. The selection of currentiy-available 
TIOResourceAssignments from a lOCardResourceUsage collection of free 
resources will cause the GetPossibieConflictFreeAssignments() method to 
return a first value (kNoConflict). The selection of lOResourceAssignments 

25 from an lOCardResourceUsage collection of resources that will be available 
after a ret)oot operation will cause the GetPossibleConflictFreeAssignments() 
method to return a second value (kNoConflictAfterBoot). This method has the 
form: 

virtual void GetPossibieConflictFreeAssignments (const 
30 TIOCardResourceUsage& possibles, 

TCollection<TIOCanjResourceUsage>& freeNow, 
TCollection<TIOCardResourceUsage>& freeAfterBoot) const; 
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An InstallQ method updates the hardware configuration database with 
the configuration infomiation for the new card added, or the change in 
configuration infonnation for an existing card. This method stores the 
appropriate value of the corresponding THardwarelnterfaceldentifier in the 
5 parent object. This method should he called only after invoking the 

aforementioned DetectResourceConflict() method so that potential resource 
conflicts can be detected before the resource assignments are stored. The 
method throws an exception if a previous call to the DetectResourceConflict() 
method returns the enumerated value (kConflict) indicating that a conflict in 

10 resource assignments has already been discovered. 

An lnvokeRecorder() method of dass 2200 is called to instantiate an 
appropriate configuration recorder object if no conflicts in resource allocation 
have been detected. This method throws an exception if there is any conflict 
in the resource allocation. For example, an exception will be thrown if a 

15 previous call to the DetectResourceConf)ict() method returned the 

enumerated value (kConflict) which indicates that an unresoivable conflict has 
been detected or the value (kNoConfiictAfterBoot) which indicates that a 
resolvable conflict has been detected. 

The TManuallOCard class 2200 further includes a method, GetTypeQ, 

20 which retums the type of the manually-configured card and a method 
SetTypeO whk:h writes the card type to a private attribute. A 
GetVendorlnfonmattonO method of dass 2200 retums the vendor Information 
arKl a SetVendorinformatk>n() method writes the vendor infonmation to 
another private attribute. 

25 A SetSk>tldentifier() method of dass 2200 writes the 

THardwarelnterfaceldentifier for the slot in which the card is plugged in a 
private attribute and a GetBusType() method retums an enumerated value, 
kManuallOCard type indicated the bus type on the board. 

A TPIugNPIaylSACard dass 2202 representing a Plug and Play ISA 

30 card indudes a plurality of methods including a 

GetPlugNPIayVersionNumber() method for reading a Plug & Play version 
number used by the card, a SetPlugNPIayVersionNumber() method for 
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setbng the Plug & Play version number used by the card, a 
GetCardRevisionNumber() method for reading the card's revision number and 
a SetCardRevisionNumberO method for setting the card's revision number. 

The class 2202 further includes a GetCardType() method for reading 
the type of the card, a SetCardType() method for setting the type of card, a 
GetSerialNumber() method for reading the serial number of the card which is 
used to distinguish two cards of same type and a SetSerialNumber() method 
fDT setting the serial number of the card. 

Also includes are a GetCaidSelectNumber() method for reading a card 
select number assigned to the card during a Plug & Play isolation phase, a 
SetCardSelectNumber() method for setting the card select number for the 
card, a GetVendorinfomiationO method for reading the vendor specific 
information for the card, a SetVendorinfomiation() method for writing the 
vendor specific infomiation for the card, a SetSlotldentifier() method for 
setting an identification code for the slot where the card is plugged in and the 
GetBusTypeO method which returns an enumerated kPlugNPIaylSA value. 

In general overview, a TRugNPIaylSACard object instantiated from the 
TPIugNPIaylSACard dass 2202 represents the behavior of a Plug & Play ISA 
card in a system. For each Plug & Play ISA card, a PlugNPIaylSACard object 
representing the card and a collection of TPIugNPIaylSAFunctionResources 
objects for the functions on the card are created and passed to the 
PlugNPIaylSACardConfigurationRecorder object 

A TPCICard dass ^04 in a like manner represents a PCI card in the 
system. Is encapsulates analogous data to a PlugNRaylSACard object 
induding the card version number, type, bus number, vendor,infonmation and 
slotlD. Similar methods are used to set and get these values from private 
attributes. 

Referring now to Figure 23. the ISA bus frameworit also indudes a 
TPIugNPIaylSAFunctionResources dass 2310 and a 
TManuallOFunctionResources dass 2306. The 

TPIugNPIaylSAFunctionResources dass 2310 represents system resources 
used by an individual function on a Plug & Play ISA card. As shown in Figure 
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23, the TPIugNPIaylSAFunctionResources class 231 0 is a subclass of the 
TIOFunctionResources dass 2314. 

The TPIugNPIaylSAFunctionResources class 2310 includes a plurality 
of member functions including a GetFunctionType() method and a 
5 SetFunctionTypeO method for respectively reading and setting the function 
type into a private attribute. A function type indicates the I/O operation 
represented by the function. 

Class 2310 also includes a method, GetCompatibleType() for reading 
a compatible device type and a method, SetCompatibleType(), for setting the 
10 compatible device type. The existence of a compatible device type indicates 
other devices compatible with the device on which the function is located. 

The TIOFunctionResources dass 2314 contains nested dasses that 
encapsulate information concerning various resources needed by the 
function. These dasses include TIORegisterRange 2304 which encapsulates 
15 information relating to I/O register ranges, TIOMemoryRange 2300 which 
encapsulates information relating to memory ranges required by the function, 
TInterruptlnformation 2302 which encapsulates information relating to 
interrupt sockets and TDMAInfomnation 2308 which encapsulates infomiation 
relating to DMA channels. 
20 Refening now to Figure 24, the ISA bus framework is shown to further 

indude a TISAStofWrthPlugNPIayiSACardldentifier dass 2408, which 
represents the THardwarelnterfeceldentifier object for a sbt Into which is 
plugged a card of the Plug & Play ISA type, a 

TISASIotWrthManuallSACardldentifier class 2406 which represents the 
25 THardwareinterfaceldentifier object for a slot Into which is plugged a card of 
the manually-configured type. Both dasses 2406 and 2408 are derived from 
a TISASIotldentifier dass 2404. The TISASIotldentifier dass 2404 represents 
the THardwareinterfaceldentifier for an ISA slot. The TISASIotldentifier dass 
2404 indudes a plurality of member functions, induding a 
30 GetFunctionResourcesO method and a SetFunctionResources() method 
which respectively read and set the function resources used by the card. 
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Class 2404 also includes a GetSlotlD() method and a SetSlotlDQ method for 
reading and setting the slof s identifier. 

The ISA bus framework also includes a 
TConfigurationRecorderLocator dass 2400, a 
5 TManuallOPossibleResourceAssignmentRetriever class 2402 and a 

TMotherboardldentifier class 2410. The TMotherboard identifier class 2410 
represents a THardwarelnter^celdentifier object created for a motherboard in 
order to store the configuration information for the mothertx)ard devices. The 
TMothertx>ardldentifier class 2410 includes a GetFunctionResources() 

10 method and a SetFunctionResources() method which, respectively, read and 
set the function resources used by the card in a private attribute. The 
TMothertx)ardldentifier class 2410 also includes a GetCard() method and a 
SetcardO method which respectively read and set the card object. 

The TManuallOPossibleResourceAssignmentRetriever class 2402 

15 instantiates an object which is responsible for retrieving the default I/O 
resource assignment and the possible I/O resource assignment information 
for a function on a specific manually-configured I/O Card such as manual ISA 
card, Local bus card or Mothertx)ard device. When the user drags a card Icon 
to a slot icon in the computer viewer, a THardwareModuleStgnature obtained 

20 firom the THardwareModule for the card is used to retrieve the constraints 
from the configuration option database. 

While the Invention has been described in temis of a prefenred 
emtxKliment in a specific system environment, those skilled in the art 
recognize that the invention can be practiced, with modification, in other and 

25 different hardware and software environments within the spirit and scope of 
the appended claims. 
What is claimed is: 
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Claims 



1 1 . In a computer system having a plurality of expansion cards and a 

2 memory, a method of assigning system I/O resources comprising the 

3 steps of: 

4 (a) creating a single global conflict resolver for resolving all resource 

5 conflicts in the computer system; 

6 (b) automatically identifying each I/O function in the computer system and 

7 obtaining resource requirements therefor; 

8 (c) formatting the resource requirements into a predetermined standard 

9 format; 

10 (d) providing the fonnatted resource requirements to the global conflict 

1 1 resolven 

12 (e) using the conflict resolver to iteratively compute a resource assignment 

13 for each I/O function which resource assignment does not conflict with 

14 other resource assignments; and 

15 (f) storing the computed each resource assignment in the memory in a 

16 standard fonmat together with a corresponding resource requirement. 

1 2. The method of daim 1 wherein step (b) comprises the steps of: 

2 (b1 ) obtaining resource requirements directly from an expansion card on 

3 which the each I/O function is bcated. 

1 3. The method of daim 2 further comprising the step of. 

2 (g) programming the expansion canj on which the each I/O function is 

3 located with a computed resource assignment. 

1 4. The method of daim 1 wherein step (b) comprises the steps of: 

2 (b2) obtaining resource requirements from a database when an expansion 

3 card on which the each I/O function is located is a manually-configured 

4 card. 
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1 5. The method of claim 4 further comprising the steps of: 

1 (h) storing resource requirements for the expansion card in a hardware 

2 configuration database when no conflicts are detected by the conflict 

3 resolver; and 

4 (i) infomning a user of the computer system when a conflict is detected by 

5 the conflict resolver. 

1 6. The method of claim 5 further comprising the steps of: 

2 (j) when a conflict is detected by the conflict resolver, determining 

3 whether conflicting resources assigned to auto-configuration expansion 

4 card can be re-assigned during a subsequent booting of the computer 

5 system. 

1 7. The method of claim 6 further comprising the step of: 

2 (k) instructing the user to reboot the computer system when conflicting 

3 resources can be reassigned in step G). 

1 8. The method of claim 7 wherein step (k) comprises the steps of. 

2 (k1 ) determining whether resource requirements for all manual expansion 

3 cards are stored in the hardware configuratbn database; aruJ 

4 (k2) instructing the user to reboot the computer system only after the 

5 resource requirements for all manual expanston cards are stored in the 

6 hardware configuration database. 

1 9. The method of claim 6, wherein step (i) comprises the step of: 

2 (i1) notifying a user that manual intervention is required to change the 

3 resource requirements of a manually-configured expansion card when 

4 conflicting resources assigned to auto-configuration expansion card 

5 cannot be re-assigned during a subsequent booting of the computer 

6 system. 
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1 10. The method of claim 1 , wherein step (b) comprises the step of: 

2 (b3) examining a system mothert>oard to identify buses attached to the 

3 motherboard; 

1 (b4) examining each bus identified In step (b3) to identify each expansion 

2 card attached to the each bus; and 

3 (b5) examining each expansion card attached to the each bus to determine 

4 I/O functions thereon. 

1 11. The method of claim 1 , wherein step (e) comprises the steps of: 

2 (el ) assigning resources to I/O functions on manually-configured cards; 

3 and 

4 (e2) assigning resources to I/O functions on auto-configured cards. 

1 12. In a computer system having a plurality of expansion cards and a 

2 memory, apparatus for assigning system I/O resources comprising: 

3 (a) a single global conflict resoh^er for resolving all resource conflicts in the 

4 computer system; 

5 (b) a plurality of recognizers for automatically identifying each I/O function 

6 in the computer system and obtaining resource requirements therefor, 

7 (c) a plurality of encapsulators for fonmatting the resource requirements 

8 into a predetermined standard format; 

9 (d) means for providing the formatted resource requirements to the global 

10 conflict resolven 

11 (e) a method in the conflict resolver for iteratively computing a resource 

12 assignment for each I/O function which resource assignment does not 

13 conflict with other resource assignments; and 

14 (f) a storage mechanism for storing the computed each resource 

15 assignment in the memory in a standard format together with a 

16 corresponding resource requirement. 
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The apparatus of claim 12 wherein each of the plurality of recognizers 
comprises means for obtaining resource requirements directly from an 
expansbn card on which the each I/O function is located. 

The apparatus of claim 13 further comprising a mechanism in each of 
the recognizers for programming the expansion card on which the 
each I/O function is located with a computed resource assignment. 

The apparatus of claim 12 wherein each of the recognizers further 
comprises an option retriever for obtaining resource requirements from 
a database when an expansion card on which the each I/O function is 
located is a manually-configured card. 

The apparatus of claim 1 5 further comprising: 

a recorder for storing resource requirements for the expansion 
card in a hardware configuratbn database when no conflicts are 
detected by the conflict resolven and 

means for infonming a user of the computer system when a 
conflict is detected by the conflict resolver. 

The apparatus of daim 16 further comprising means, responsive to the 
detection of a conflict by the conflict resolver, for determining whether 
conflicting resources assigned to auto-configuration expansion card 
can be re-assigned during a subsequent booting of the computer 
system. 

The apparatus of daim 17 further comprising a conflict mechansim for 
instnjcting the user to reboot the computer system when conflicting 
resources can be reassigned. 

The apparatus of daim 18 wherein the conflict mechanism comprises: 
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2 means for determining whether resource requirements for all 

3 manual expansion cards are stored in the hardware configuration 

4 database; and 

1 means for instructing the user to reboot the computer system 

2 only after the resource requirements for all manual expansion cards 

3 are stored in the hardware configuration database. 

1 20. The apparatus of claim 1 7, wherein the means for determining whether 

2 conflicting resources can t>e reassigned comprises means for notifying 

3 a user that manual intervention is required to change the resource 

4 requirements of a manually-configured expansion card when 

5 conflicting resources assigned to auto-configuratton expansion card 

6 cannot be re-assigned during a subsequent booting of the computer 

7 system. 

1 21 . The apparatus of daim 12» wherein each of the recognizers comprises: 

2 means for examining a system motherboard to identify buses 

3 attached to the mothert)oard; 

4 means for examining each bus identified in step (b3) to identify 

5 each expansion card attached to the each bus; and 

6 means for examining each expansion card attached to the each 

7 bus to detemiine I/O functions thereon. 

1 22. The apparatus of claim 1 2. wherein the esource assignment computing 

2 method comprises: 

3 means for initially assigning resources to I/O functions on 

4 manually-configured cards; and 

5 means for subsequently assigning resources to I/O functions on 

6 auto-configured cards. 
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1 23. A computer program product for use in a computer system having a 

2 plurality of expansion cards and a memory, a computer program 

3 product assigning system I/O resources and comprising a computer 

4 usable medium having computer readable program code thereon. 

5 including: 

6 (a) program code for creating a single global conflict resolver for resolving 

7 all resource conflicts in the computer system; 

8 (b) program code for automatically identifying each I/O function in the 

9 computer system and obtaining resource requirements therefor; 

10 (c) program code for formatting the resource requirements into a 

11 predetermined standard format; 

12 (d) program code for providing the formatted resource requirements to the 

13 global conflict resolver; 

14 (e) program code for using the conflict resolver to iteratively compute a 

15 resource assignment for each I/O function which resource assignment 

16 does not conflict with other resource assignments: and 

17 (f) program code for storing the computed each resource assignment in 

18 the memory in a standard format together with a conresponding 

19 resource requirement. 

1 24. The computer program product of daim 23 wherein the program code 

2 for automatically identifying each I/O function comprises program code 

3 for obtaining resource requirements directly from an expansion card on 

4 which the each I/O function is focated. 

1 25. The computer program product of claim 24 further comprising program 

2 code for programming the expansion card on which the each I/O 

3 function is located with a computed resource assignment. 

1 26. The computer program product of claim 23 wherein the program code 

2 for automatically identifying each I/O fiinctioncomprises program code 
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3 for obtaining resource requirements from a database when an 

4 expansion card on which the each I/O function is located is a manuaily- 

5 configured card. 

1 27. The computer program product of claim 26 further comprising: 

2 program code for storing resource requirements for the 

3 expansion card in a hardware configuration database when no conflicts 

4 are detected by the conflict resolver, and 

5 program code for informing a user of the computer system when 

6 a conflict is detected by the conflict resolver. 

1 28. The computer program product of daim 27 further comprising program 

2 code, operative when a conflict is detected by the conflict resolver. for 

3 determining whether conflicting resources assigned to auto- 

4 configuration expansbn card can be re-assigned during a subsequent 

5 booting of the computer system. 

1 29. The computer program product of daim 28 further comprising program 

2 code for instructing the user to reboot the computer system when 

3 conflicting resources can be reassigned. 

1 30. The computer program product of daim 29 wherein the program code 

2 for instructing the user to reboot the computer system comprises: 

3 program code for determining whether resource requirements 

4 for all manual expansion cards are stored in the hardware 

5 configuration database; and 

6 program code for instructing the user to retxx)t the computer 

7 system only after the resource requirements for all manual expansion 

8 cards are stored in the hardware configuration database. 
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1 31 . The computer program product of claim 28, wherein the program code 

2 for determining whether conflicting resources can be re-assigned 

3 comprises program code for notifying a user that manual intervention is 

4 required to change the resource requirements of a manuaily- 

5 configured expansion card when conflicting resources assigned to 

6 auto-configuration expansion card cannot be re*assigned during a 

7 subsequent booting of the computer system. 

1 32. The computer program product of claim 23, wherein the program code 

2 for automatically identifying each I/O function comprises: 

3 program code for examining a system motherboard to identify 

4 buses attached to the motheri3oard; 

5 program code for examining each bus identified in step (t>3) to 

6 identify each expansion card attached to the each bus; and 

7 program code for examining each expansion card attached to 

8 the each bus to determine I/O functions thereon. 

1 33. The computer program product of daim 23, wherein the program code 

2 for using the conflict resolver comprises: 

3 program code for assigning resources to I/O functions on 

4 manually-configured cards; and 

5 program code for assigning resources to I/O functions on auto- 

6 configured cards. 

1 34. An apparatus for resolving a resource conflict which occurs while 

2 adding an expansion card to a computer system, the apparatus 

3 comprising: 

4 (a) a processor; 

5 (b) a storage device, coupled to and under the control of the processor, 

6 the storage having a plurality of storage locations; 
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7 (c) at least one manually-configured expansion card coupled to the 

8 processor, each of the at least one manually-configured expansion 

9 cards for providing at least one I/O function; 

1 (d) a computer hardware configuration database stored in the storage 

2 device, the computer hardware configuration database having a 

3 database entry for each of the at least one manually-configured 

4 expansion cards coupled to the processor, each of the database 

5 entries having a list of computer resources required by the 

6 corresponding manually-configured expansion card; 

7 (e) a card recognizer for identifying each of the at least one manually- 

8 configured I/O expansion cards and for retrieving computer resource 

9 requirements for each of the manually-configured I/O expansion cards 

10 from the hardware configuration database; and 

1 1 (f) a resource conflict resolver module for receiving the computer resource 

12 requirements for each of the manually-configured I/O expansion cards 

13 from the card recognizer and for determining whether a conflict in 

14 resource assignments exists. 

1 35. The apparatus of claim 34 wherein the resource conflict resolver 

2 module further comprises: 

3 means for identifying an I/O function involved in a resource 

4 conflict between a first one of the at least one manually-configured 

5 expansbn cards and a device coupled to the processor, and 

6 means for providing, to a user, information explaining why a 

7 particular I/O function could not be assigned a particular computer 

8 resource wherein in response to a resource conflict in the resource 

9 assignment for an individual I/O fonction being identified, the means for 

10 providing provides to the user information explaining why the I/O 

11 function could not be assigned to a particular computer resource and 

12 what other I/O fonctions are involved in the resource confiict. 
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1 36. The apparatus of claim 35 wherein the resource conflict resotver 

2 module further comprises means for assigning a particular resource to 

3 a particular I/O function. 

1 37. A resource manager comprising: 

2 means for identifying each of a plurality of expansion cards 

3 coupled to a computer system; 

1 means for maintaining infomnation on I/O functions on each of 

2 the plurality of expansion cards; 

3 means for assigning a computer resource to each of the plurality 

4 of expansion cards; 

5 means for identifying a conflict in computer resource 

6 assignments; and 

7 means for resolving conflicts in the computer resource 
a assignments. 

1 38. The resource manager of daim 37 wherein said means for resolving 

2 conflicts in resource assignments is provided as a resource conflict 

3 object having a plurality of attritnites and a plurality of member 

4 functions, wherein at least some of the attributes of the resource 

5 conflict object correspond to information explaining why a particular I/O 

6 function can not be assigned a particular computer resource and 

7 wherein the resource conflict object identifies a conflicting resource^ 

8 identifies an assignment period conresponding to a conflicting 

9 assignment period and identifies one conflicting resource index from a 
10 plurality of conflicting resource indices. 

1 39. The resource manager of claim 38 wherein: 

2 the means for maintaining infonnation on I/O functions on each 

3 of the plurality of expansion cards is provided as a first method of a 

4 resource conflict resolver object for registering the possible resource 
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5 assignments for all I/O functions on at least one of an expansion card 

6 and a motherboard; 

7 the means for assigning a computer resource to each of the 

8 plurality of expansion cards is provided as a second method of the 

9 resource conflict resohrer object; and 

10 the means for identifying a conflict in computer resource 

11 assignments is provided as a third method of the resource conflict 

12 resolver object. 

1 40. The resource manager of claim 39 wherein the means for identifying 

2 each of a plurality of expansion cards coupled to a computer system is 

3 provided as a predetenmined one of a plurality of recognizer objects 

4 wherein: 

5 a first one of the plurality of recognizer objects is provided 

6 having a fist method for retrieving resource requirements for I/O 

7 functions on a manually-configured I/O expansion card from a 

8 hardware configuration database and a second method for registering 

9 the resource requirements with a resource conflict resolver 

10 

11 41 . The resource manager of daim 40 wherein the system resources are 

12 provided as at least one ot 

13 (a) a memory range; 

14 (b) an input-output register range; 

15 (c) an interrupt request signal; and 

16 (d) a direct memory access channel. 

1 42. A method of initializing a computer system comprising the steps of: 

2 (a) loading a computer operating system into the computer system; 

3 (b) instantiating a boot conductor object from a l>ooting system; 

4 (c) instantiating, via the boot conductor object, a manual recorder 

5 registry object from a manual recorder registry class; 
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6 (d) instantiating, via the manual recorder registry object, a 

7 mothert)oard configuration recorder object from a motherboard 
a configuration recorder dass; 

9 (e) instantiating, via the manual recorder registry object, a second 

10 level recognizer object for a motherboard; 

11 (f) instantiating, via the manual recorder registry object, a second 

12 level recognizer object for each of a plurality of manual 

13 expansion cards; 

1 (g) registering, via the motherboard configuration recorder object, 

2 resource requirements for I/O functions which are provided as 

3 an Integral part of the motherboard with a resource conflict 

4 resolven 

5 (h) instantiating, via a motherboard configuration recorder object, a 

6 card recognizer object for each expansion bus provided as part 

7 of the mothertx>ard; 

8 (i) for each expansion bus, Identifiing, via the respective card 

9 recognizer object, each expansbn card on the expansion bus; 

10 <j) identifying, via the card recognizer, I/O functions for each 

1 1 expansion card identified in the identifying each expansion card 

12 step; 

13 (k) identifying, via the card recognizer, resource requirements for 

14 each of the I/O functions I/O functions for each expansion card 

15 identified in the identifying each expansion card step; 

10 (I) registering, via the card recognizer, the resource requirements 

17 for the I/O functions on each expansion card with the conflid 

18 resolven and 

19 (ml) computing, via the conflict resolver, a conflict-firee resource 

20 assignment from the resource requirements registered therein 

21 by the card recognizer. 

1 43. The method of daim 42 further wherein the step of registering the 

2 resource requirements for the I/O fonctions on each expansion card 
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wrth the resource conflict resolver includes the step of storing the 
resource requirements for the I/O functions on each expansion card in 
a hardware configuration database. 

44. The method of daim 43 wherein the step of registering the resource 
requirements for the I/O functions on the mothertK)ard with the 
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